Bug 46281 - [chromium] add baselines for xmlhttprequest tests for chromium
Summary: [chromium] add baselines for xmlhttprequest tests for chromium
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other OS X 10.5
: P2 Normal
Assignee: Tony Chang
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-22 11:14 PDT by Tony Chang
Modified: 2010-09-22 17:45 PDT (History)
2 users (show)

See Also:


Attachments
Patch (5.50 KB, patch)
2010-09-22 11:15 PDT, Tony Chang
levin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Chang 2010-09-22 11:14:41 PDT
[chromium] add baselines for xmlhttprequest tests for chromium
Comment 1 Tony Chang 2010-09-22 11:15:52 PDT
Created attachment 68400 [details]
Patch
Comment 2 Tony Chang 2010-09-22 11:22:21 PDT
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.
Comment 3 David Levin 2010-09-22 15:54:00 PDT
(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.
Comment 4 Tony Chang 2010-09-22 16:26:07 PDT
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.
Comment 5 Tony Chang 2010-09-22 16:34:23 PDT
Opera on Windows always sends Content-Length: 0.
Comment 6 David Levin 2010-09-22 17:28:23 PDT
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.
Comment 7 Tony Chang 2010-09-22 17:45:39 PDT
Committed r68104: <http://trac.webkit.org/changeset/68104>