Bug 82202 – Make XHR POST and PUT Content-Length sending behavior explicit on XHR level

• Component: WebCore JavaScript
• Status: RESOLVED WONTFIX

[Dominik Röttsches (drott)]

Following the discussion and observations on bug 82036, I suggest to align XmlHttpRequest's behavior for sending Content-Length with other browser implementations. 

All tested browser implementations (FF, Opera, IE, Chromium) send a zero Content-Length Header on an empty (send()) as well as on a zero-length body (send("")). However, WebKit does not make that explicit in the XHR code and leaves it to the HTTP backend which leads to a variation in tests results.

So, WebKit should send a zero Content-Length header in POST/PUT cases for empty as well as zero-length http body.

[Dominik Röttsches (drott)]

Created attachment 133840 [details]
XHR Sending Content Length for zero-sized and empty POST & PUT

When I implement a change to XMLHttpRequest like in this patch adding the Content-Length: header for empty and zero sized bodies and POST & PUT case in method createRequest() I run into a couple of failures for
http/tests/xmlhttprequest/access-control-*.html which tell me:
"Request header field Content-Length is not allowed by Access-Control-Allow-Headers."

So is this something that we know need to circumvent on the XHR level / exempt from the header checking? (If so, any suggestions how?)

Or does this mean we're back to a point where it's better to implement that change at the HTTP level?

[Alexey Proskuryakov]

The rule is that the engine can send whatever headers it deems correct, but JavaScript code can only change most header fields if explicitly allowed by a CORS reply from server. And some header fields cannot be set at all, regardless of CORS.

[Dominik Röttsches (drott)]

Thanks, Alexey. The architectural problem I am facing here is that any header manipulation inside XHR code that is relevant for CORS is detected by the security checks that are invoked downstream of
http://trac.webkit.org/browser/trunk/Source/WebCore/xml/XMLHttpRequest.cpp#L728 (ThreadableLoader::create, then CrossOriginPreflightResultCacheItem::allowsCrossOriginHeaders)

So, in my current understanding, we would either need some kind of dangerous and ugly circumvention, like
ThreadableLoaderOptions options.crossOriginRequestPolicy = UseAccessControlButAllowMeToSetContentLength;

or go back to the initial approach and intercept empty and non-zero POST/PUT requests below the CORS/DocumentThreadable loader level on the ResourceRequest or  the specific libsoup backend level. (The other HTTP backends seem to behave correctly already.)

Maybe I miss something - so other suggestions are very welcome. Otherwise at this point I would say, let's fix it at the libsoup level. What do you think, Dan, Alexey?

[Dan Winship]

If the organization of the XHR code makes this difficult to do at the XHR level then sure, do it in the soup backend.

[Dominik Röttsches (drott)]

Back to the soup level, will provide patch in bug 82036.