82202 2012-03-26 07:06:55 -0700 Make XHR POST and PUT Content-Length sending behavior explicit on XHR level 2012-04-02 02:05:25 -0700 1 1 1 Unclassified WebKit WebCore JavaScript 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 1 d-r webkit-unassigned ap danw gustavo rakuco oldest_to_newest 587695 0 d-r 2012-03-26 07:06:55 -0700 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. 587857 1 133840 d-r 2012-03-26 10:05:47 -0700 Created attachment 133840 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? 587910 2 ap 2012-03-26 11:00:38 -0700 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. 588737 3 d-r 2012-03-27 04:12:10 -0700 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? 592126 4 danw 2012-03-30 06:40:03 -0700 If the organization of the XHR code makes this difficult to do at the XHR level then sure, do it in the soup backend. 593262 5 d-r 2012-04-02 02:05:25 -0700 Back to the soup level, will provide patch in bug 82036. 133840 2012-03-26 10:05:47 -0700 2012-03-26 10:05:47 -0700 XHR Sending Content Length for zero-sized and empty POST & PUT XHR_CL.patch text/plain 974 d-r ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL3htbC9YTUxIdHRwUmVxdWVzdC5jcHAgYi9Tb3Vy Y2UvV2ViQ29yZS94bWwvWE1MSHR0cFJlcXVlc3QuY3BwCmluZGV4IDcxMjIwMGMuLjA2ODliOTMg MTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL3htbC9YTUxIdHRwUmVxdWVzdC5jcHAKKysrIGIv U291cmNlL1dlYkNvcmUveG1sL1hNTEh0dHBSZXF1ZXN0LmNwcApAQCAtNzAzLDYgKzcwMywxNSBA QCB2b2lkIFhNTEh0dHBSZXF1ZXN0OjpjcmVhdGVSZXF1ZXN0KEV4Y2VwdGlvbkNvZGUmIGVjKQog ICAgICAgICByZXF1ZXN0LnNldEhUVFBCb2R5KG1fcmVxdWVzdEVudGl0eUJvZHkucmVsZWFzZSgp KTsKICAgICB9CiAKKyAgICAvLyBJbiBsaW5lIHdpdGggb3RoZXIgYnJvd3NlcnMgbGlrZSBGRiBh bmQgdGhlIEhUVFAgYmFja2VuZCBvZiBDaHJvbWl1bSB3ZQorICAgIC8vIGV4cGxpY2l0bHkgc2Vu ZCBhIENvbnRlbnQtTGVuZ3RoOiAwIGhlYWRlciBmb3IgZW1wdHkKKyAgICAvLyBhcyB3ZWxsIGFz IHplcm8tc2l6ZWQgUE9TVCBhbmQgUFVUIGJvZGllcywgaS5lLiBzZW5kKCkgJiBzZW5kKCIiKS4K KyAgICBpZiAoKG1fbWV0aG9kID09ICJQT1NUIiB8fCBtX21ldGhvZCA9PSAiUFVUIikKKyAgICAg ICAgJiYgKCFtX3JlcXVlc3RFbnRpdHlCb2R5CisgICAgICAgICAgICB8fCBtX3JlcXVlc3RFbnRp dHlCb2R5LT5pc0VtcHR5KCkKKyAgICAgICAgICAgIHx8IChtX3JlcXVlc3RFbnRpdHlCb2R5LT5l bGVtZW50cygpLnNpemUoKSA9PSAxICYmICFtX3JlcXVlc3RFbnRpdHlCb2R5LT5mbGF0dGVuVG9T dHJpbmcoKS5sZW5ndGgoKSkpKQorICAgICAgICBzZXRSZXF1ZXN0SGVhZGVySW50ZXJuYWwoIkNv bnRlbnQtTGVuZ3RoIiwgIjAiKTsKKwogICAgIGlmIChtX3JlcXVlc3RIZWFkZXJzLnNpemUoKSA+ IDApCiAgICAgICAgIHJlcXVlc3QuYWRkSFRUUEhlYWRlckZpZWxkcyhtX3JlcXVlc3RIZWFkZXJz KTsKIAo=