[Webkit-unassigned] [Bug 136938] The XMLHttpRequest should suppourt method responseURL As per latest Spec

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=136938





--- Comment #5 from Shivakumar J M <shiva.jm at samsung.com>  2014-09-21 02:21:20 PST ---
(In reply to comment #4)
> (From update of attachment 238368 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=238368&action=review
> 
> responseURL only exists in WhatWG version of XHR spec, <https://xhr.spec.whatwg.org/#the-responseurl-attribute>, and this spec does not appear to be very polished yet. Has it been through any kind of security review? Do other browsers implement this?
> 
> The definition of responseURL is: "The responseURL attribute must return the empty string if response's url is null and its serialization otherwise." The definition of response's url is in Fetch spec, <https://fetch.spec.whatwg.org/#concept-response-url>.
> 
> But in the Fetch spec, it's defined to always be the request URL, it doesn't change with redirects!
> 
> Another thing that I noticed is that the Fetch spec has a concept of Response object and its URL, which filters out fragment identifiers - and XHR spec does not filter them out for responseURL. This is an inconsistency that needs to be resolved.
> 
> > LayoutTests/http/tests/xmlhttprequest/xmlhttprequest-responseURL.html:3
> > +<script src="../../../../js-test-resources/js-test.js"></script>
> 
> The relative path is not needed, can be just "/js-test-resources/js-test.js".
> 
> > LayoutTests/http/tests/xmlhttprequest/xmlhttprequest-responseURL.html:14
> > +    if (req.readyState == 3) {
> 
> We should test responseURL in every state, not just in state 3.
> 
> We should test various unusual URLs in Location field, notably:
> - ones with fragments;
> - ones with user credentials;
> - ones that are absolute vs. relative.
> 
> > LayoutTests/http/tests/xmlhttprequest/xmlhttprequest-responseURL.html:30
> > +<script src="../../../../js-test-resources/js-test.js"></script>
> 
> Same comment about path.

Dear Darin and Alexey,

     Thanks for the inputs, below are my observations:

     1) Since null check is not needed, we can just have these code "return m_response.url().string();" in XMLHttpRequest::responseURL() API, will add const to these new XMLHttpRequest::responseURL() API.
     2) I will add more tests for response URL null case, the response URL is not exactly the same as the request URL case and redirect cases etc. 
     3) I will check why, in existing test case exactly 5 pieces are coming. Is that reliable or could this test be flaky?     
     4) This spec still needs to be polished and undergo security review. 
I just checked Blink latest version, responseURL() API has been added in Blink.
     5) I will add tests for various unusual URLs in Location field, ones with fragments, ones with user credentials, ones that are absolute vs. relative.
     6) I will make correction for relative path in test cases, will test responseURL in every state.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.