Bug 46281 – [chromium] add baselines for xmlhttprequest tests for chromium

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Tony Chang]

[chromium] add baselines for xmlhttprequest tests for chromium

[Tony Chang]

Created attachment 68400 [details]
Patch

[Tony Chang]

We switched from lighttpd to apache on mac & linux, so these 3 tests should pass.  http/tests/xmlhttprequest/methods-lower-case.html passes with no changes.

http/tests/xmlhttprequest/methods-async.html and http/tests/xmlhttprequest/methods.html differ by the following lines:

-DELETE(null): DELETE(0 bytes), Content-Type: null
+DELETE(null): DELETE(null bytes), Content-Type: null
-WKFOOBAR(null): WKFOOBAR(0 bytes), Content-Type: null
+WKFOOBAR(null): WKFOOBAR(null bytes), Content-Type: null
-SEARCH(null): SEARCH(0 bytes), Content-Type: null
+SEARCH(null): SEARCH(null bytes), Content-Type: null

Upon further inspection, it seems that CF adds a Content-Length: 0 header to these requests.  Here's a test case that echoes the request headers:
  http://ponderer.org/tests/xhrtest.html

In Safari, there's a Content-Length parameter, but Chromium doesn't have one.  I traced through the ResourceHandleMac code and up until the point where we pass the request on to CF, ResourceRequest doesn't have a Content-Length header so I don't think any code in WebCore is adding it.

This patch just rebaselines the test, but if you want, I can also try to change our networking stack to match CF.

[David Levin]

(In reply to comment #2)
> We switched from lighttpd to apache on mac & linux, so these 3 tests should pass.  http/tests/xmlhttprequest/methods-lower-case.html passes with no changes.
> 
> http/tests/xmlhttprequest/methods-async.html and http/tests/xmlhttprequest/methods.html differ by the following lines:
> 
> -DELETE(null): DELETE(0 bytes), Content-Type: null
> +DELETE(null): DELETE(null bytes), Content-Type: null
> -WKFOOBAR(null): WKFOOBAR(0 bytes), Content-Type: null
> +WKFOOBAR(null): WKFOOBAR(null bytes), Content-Type: null
> -SEARCH(null): SEARCH(0 bytes), Content-Type: null
> +SEARCH(null): SEARCH(null bytes), Content-Type: null
> 
> Upon further inspection, it seems that CF adds a Content-Length: 0 header to these requests.  Here's a test case that echoes the request headers:
>   http://ponderer.org/tests/xhrtest.html
> 
> In Safari, there's a Content-Length parameter, but Chromium doesn't have one.  I traced through the ResourceHandleMac code and up until the point where we pass the request on to CF, ResourceRequest doesn't have a Content-Length header so I don't think any code in WebCore is adding it.
> 
> This patch just rebaselines the test, but if you want, I can also try to change our networking stack to match CF.

Is it possible to try out FF and IE and see what they do for the test?

If they do what Safari does, then it seems taht chromium should follow suit.
If not, then a difference may be fine here.

[Tony Chang]

In IE9:
DELETE sends a content-length of 0.   wkfoobar and search don't send a request at all (there's no request in the F12 developer tools).  I guess IE9 has a whitelist of HTTP actions?

In Firefox 3.6 Linux:
No content-length sent for DELETE, WKFOOBAR, or SEARCH.

[Tony Chang]

Opera on Windows always sends Content-Length: 0.

[David Levin]

Comment on attachment 68400 [details]
Patch

OK,browsers are inconsistent on this minor point and we're consistent with one of the many behaviors, so this seems fine.

[Tony Chang]

Committed r68104: <http://trac.webkit.org/changeset/68104>