New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 759498 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Feature



Sign in to add a comment

PATCH requestBody not captured in onBeforeRequest

Reported by tame...@gmail.com, Aug 28 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce the problem:
I noticed that http PATCH requests don't have requestBody in webRequest onBeforeRequest API?

This is the code to reproduce:
 var RequestFilter = {};
 var MatchPatterns;           
MatchPatterns = ['http://*/*', 'https://*/*'];

RequestFilter.urls = MatchPatterns;
chrome.webRequest.onBeforeRequest.addListener(onBeforeRequest, RequestFilter,
                ['requestBody']);

        function onBeforeRequest(info) {
    console.log("onBeforeRequest");
    console.log(info);
    }

Please note that POST requests have info.requestBody set while PATCH don't. Is this a bug? Is there another way to catch request body of a PATCH?

What is the expected behavior?
onBeforeRequest API should return info.requestBody if extraInfoSpec contains 'requestBody' according to documentation
https://developer.chrome.com/extensions/webRequest

What went wrong?
In case of PATCH requests info.requestBody is not set.

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 60.0.3112.90  Channel: n/a
OS Version: OS X 10.12.6
Flash Version:
 
backend.js
354 bytes View Download
Components: Platform>Extensions>API
Labels: -Hotlist-Interop
Cc: susanjuniab@chromium.org
Labels: Needs-Triage-M60 Needs-Feedback
tamerzg@ Thanks for the issue.

Can you please provide us the test file where you are seeing this issue, as this will help in further triaging of the issue.

Thanks..

Comment 3 by woxxom@gmail.com, Aug 29 2017

susanjuniab@chromium.org, this is a feature request, actually.

The feature is not implemented as you can see in the source code [1], 
but only an extension API developer can answer whether it's possible to implement.

  if (!upload_data ||
      (request->method() != "POST" && request->method() != "PUT"))
    return;

The check above for POST and PUT wasn't changed since it was added in r156547 five years ago.

  [1]: https://cs.chromium.org/chromium/src/extensions/browser/api/web_request/web_request_event_details.cc?l=79&rcl=84546bfdaffcaf6f67d4e8a4950b666e23ff1d53
Labels: -Type-Bug -Needs-Feedback Type-Feature
Status: Untriaged (was: Unconfirmed)
Untriaging it so that issue gets addressed.

Thanks.!
Cc: karandeepb@chromium.org rdevlin....@chromium.org rsleevi@chromium.org
Status: Available (was: Untriaged)
I don't think there's any fundamental reason we can't/shouldn't do this (at least for read-only access, as with put and post).  rsleevi@, is there a reason this would be bad?
Cc: mkwst@chromium.org mmenke@chromium.org
Components: Internals>Network>HTTP
CC'ing mmenke@ and mkwst@ and adding the HTTP tag. I presume these PATCH requests are generated by XHR/fetch(), since Chrome itself wouldn't generate such requests.

Off the top of my head, I can't think of any fundamental reason it'd be bad. The only reason I can think for that check would be for ensuring we consider each method and make sure it's sane, but I think PATCH should be sane.

Mike: Can you think of any concerns from a Web Platform-y perspective?
Matt: Can you think of any concerns from a //net invariants-around-HTTP perspective?

Comment 7 by mmenke@chromium.org, Mar 21 2018

Components: -Internals>Network>HTTP

Sign in to add a comment