Intent to implement and ship: XMLHttpRequest.prototype.responseURL
1,046 views
Skip to first unread message
Yutaka Hirano
May 27, 2014, 1:53:31 AM5/27/14
to blink-dev
Contact emails
Spec
http://xhr.spec.whatwg.org/#the-responseurl-attribute
Summary
The responseURL attribute was introduced in XMLHttpRequest this February([1], [2]). I would like to implement and ship the attribute.
Motivation
The attribute was introduced to make it enable to get the response URL for non-document resources.
Compatibility Risk
The feature is fairly small.
As it was specified and Mozilla already implemented it[3], I think compatibility risk is low.
Ongoing technical constraints
None
Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes
OWP launch tracking bug?
None.
There is a usual bug http://crbug.com/377583 .
Link to entry on the feature dashboard
None
Requesting approval to ship?
Yes.
1: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15417
2: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0470.html
PhistucK
May 27, 2014, 1:59:21 AM5/27/14
to Yutaka Hirano, blink-dev
If the request were redirected, does the response URL refer to the final URL, post redirection?
The specification does not say it does, so I guess not, but I think that would be more useful?
The specification does not say it does, so I guess not, but I think that would be more useful?
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
PhistucK
May 27, 2014, 2:15:50 AM5/27/14
to Yutaka Hirano, blink-dev
And also more correct?
So if this is not the actual response URL, it should be requestURL.
So if this is not the actual response URL, it should be requestURL.
☆PhistucK
Yutaka Hirano
May 27, 2014, 3:24:27 AM5/27/14
to PhistucK, blink-dev
I think it is intended to be the final URL.
Anne van Kesteren
May 27, 2014, 3:26:45 AM5/27/14
to PhistucK, Yutaka Hirano, blink-dev
On Tue, May 27, 2014 at 7:58 AM, PhistucK <phis...@gmail.com> wrote:
> If the request were redirected, does the response URL refer to the final
> URL, post redirection?
Yes.
> If the request were redirected, does the response URL refer to the final
> URL, post redirection?
--
http://annevankesteren.nl/
Darin Fisher
May 27, 2014, 2:03:45 PM5/27/14
to Yutaka Hirano, blink-dev
LGTM
TAMURA, Kent
May 27, 2014, 7:22:32 PM5/27/14
to Darin Fisher, Yutaka Hirano, blink-dev
LGTM2.
- Small addition to an existing feature
- The feature looks useful.
- Mozilla implemented it.
--
TAMURA Kent
Software Engineer, Google
TAMURA Kent
Software Engineer, Google
Eric Seidel
May 27, 2014, 7:25:34 PM5/27/14
to Darin Fisher, Yutaka Hirano, blink-dev
As an incremental improvement to XHR, makes sense. Begs the question
in my mind as to why we don't expose a whole response object with
attributes like "url".
I wonder what a holistic comparison of the API surface of XHR vs. some
other networking API (like CFNetwork?) looks like. Presumably XHR is
much less powerful, but there is much question as to how much of that
"power" matters.
In any case, I don't have particularly strong opinions on this one and
defer to other experts. One other browser shipping and a spec = LGTM.
in my mind as to why we don't expose a whole response object with
attributes like "url".
I wonder what a holistic comparison of the API surface of XHR vs. some
other networking API (like CFNetwork?) looks like. Presumably XHR is
much less powerful, but there is much question as to how much of that
"power" matters.
In any case, I don't have particularly strong opinions on this one and
defer to other experts. One other browser shipping and a spec = LGTM.
Joshua Bell
May 27, 2014, 7:39:43 PM5/27/14
to Eric Seidel, Darin Fisher, Yutaka Hirano, blink-dev
On Wed, May 28, 2014 at 1:25 AM, Eric Seidel <ese...@chromium.org> wrote:
As an incremental improvement to XHR, makes sense. Begs the question
in my mind as to why we don't expose a whole response object with
attributes like "url".
In progress as part of the Service Worker effort:
One line of thinking that's been batted about is that the Request and Response types would be moved out of the SW spec into the Fetch spec, and Fetch grows an actual API e.g. fetch(Request) => Promise<Response>. At that point, XHR itself might be deprecated.
Anne van Kesteren
May 28, 2014, 3:34:00 AM5/28/14
to Joshua Bell, Eric Seidel, Darin Fisher, Yutaka Hirano, blink-dev
On Wed, May 28, 2014 at 1:39 AM, Joshua Bell <jsb...@chromium.org> wrote:
> One line of thinking that's been batted about is that the Request and
> Response types would be moved out of the SW spec into the Fetch spec, and
> Fetch grows an actual API e.g. fetch(Request) => Promise<Response>. At that
> point, XHR itself might be deprecated.
Started working on that: http://fetch.spec.whatwg.org/#fetch-api
> One line of thinking that's been batted about is that the Request and
> Response types would be moved out of the SW spec into the Fetch spec, and
> Fetch grows an actual API e.g. fetch(Request) => Promise<Response>. At that
> point, XHR itself might be deprecated.
As for exposing a Response objects on XMLHttpRequest, I suppose we
could do that at some point through the responseType/response
attribute set if there's a use. The solution I added to expose a
response's url is more in line with how the rest of the API is
designed and it was the only missing piece of response objects. So
adding a dependency on Response objects seemed overkill.
--
http://annevankesteren.nl/
Elliott Sprehn
May 28, 2014, 4:31:41 AM5/28/14
to Anne van Kesteren, Joshua Bell, Eric Seidel, Darin Fisher, Yutaka Hirano, blink-dev
Adding a Response object is a lot of overhead in the implementation on XMLHttpRequest which we plan to deprecate and replace with fetch() anyway. I'd rather we did the minimum necessary to change it and then moved forward with fetch.
That seems to be what you've already done, so I say lets stick to it.
- E
Reply all
Reply to author
Forward
Message has been deleted
0 new messages