742508 - Figure out best UI for redirects with empty Location headers

Status: RESOLVED INVALID

(Core :: Networking: HTTP, enhancement)

Description

[Jason Duell]

Attachment: Renders 3xx body if Location header is blank

Historically for empty Location headers we wind up treating the empty string as a relative URI, redirect back to the originating URI, and if it redirects us again, aborting the navigation (user stays on same page they were at before).  For a *missing* Location header, we render the 3xx body.

Attached patch changes our behavior to also render 3xx body if Location is empty.  This is what Chrome 18 is doing.  

A case could be made that the redirect-to-same-URI approach is spec compliant (see bug 742174 comment 4) and/or more secure, in case a CRLF attack is what's causing the empty redirect (see  bug 716801 comment 8).  In that case I'd suggest that we issue some sort of error page rather than just cancel navigation.   But since I'm not sure what's actually going on to cancel the navigation, I'm not sure how easy it would be to do that.  And I don't consider this edge case important enough to investigate at the moment.  So I'm marking this as an enhancement for now.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

It seems like the attached patch ignores the response status code if the Location header is empty OR if it is blank.

The first question is whether we need to distinguish between the case of a missing Location header and an empty Location header.

It has been claimed that Chrome will render the response body of a 302 response if there is a blank Location header. Will it also render the response body if there is *no* Location header in a 302 response? How does Chrome's XHR implementation work when it receives a 302 with an empty Location header? How does its WebSockets handshake work when it receives a 302 with an empty Location header as part of that handshake?

In some other bug, it was claimed that MSIE will treat a blank Location header as a a redirect to "", i.e. a redirect to the request URI. This claim should be verified. Obviously, this is a redirect loop. AFAICT, we already have implemented mechanisms to break such redirect loops and do the correct thing, if we want to match the MSIE behavior.

I think what Chrome is doing is wrong, and unless there are many sites that rely on that behavior on the internet, we should not treat a 3xx response as a 200 response--especially in XHR, in the WebSockets handshake, etc.--unless we have a very compelling real-world requirement to fulfill. Are there any real-world websites that we know of that have the Chrome behavior?

Consequently, if MSIE and/or other implementations (Safari, iPhone browser, Opera) all have consistent behavior, I think we're better off with that MSIE behavior. The MSIE behavior does make some sense, as long as we account for the possibility of having to break of out infinite redirect loops. 

Alternatively, if there is no consistent behavior between any major browsers then we perhaps we could just all agree to standardize on "Return an error on missing or blank Location in a redirect that requires a Location" behavior based on the premise that we feel that no website really intends for "Location: " to be a redirect to the request-URI. However, it seems to me that we will run into this case in the future many times because I bet there are some URI libraries that have a generate_relative_ref(base, target) URI that will return "" when base == target. After all, <a href=""> and <link rel="whatever" href=""> are valid.

Also, keep in mind that a 201 response with "Location:" meaning "the resource was created at the request-URI" makes perfect sense for PUT and PATCH (and POST?).

Also, perhaps it is a good idea for the HTTPbis spec to specifically call out the case of an empty Location header in a 3xx redirect and in a 201 response (if it doesn't already).

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Brian Smith (:bsmith) from comment #1)
> However, it seems to
> me that we will run into this case in the future many times because I bet
> there are some URI libraries that have a generate_relative_ref(base, target)
> URI that will return "" when base == target. After all, <a href=""> and
> <link rel="whatever" href=""> are valid.

s/URI that will/API that will/

Comment 3

[Adam Barth]

I seem to remember an email thread on this topic, but I can't seem to find it in my inbox.  :(

Comment 4

[Julian Reschke]

(In reply to Brian Smith (:bsmith) from comment #1)
> ...
> Also, keep in mind that a 201 response with "Location:" meaning "the
> resource was created at the request-URI" makes perfect sense for PUT and
> PATCH (and POST?).
> ...

PATCH maybe, POST probably, PUT: not really. If PUT returns 201 the created resource *must* be the one identified by the request-URI anyway.

Comment 5

[Jason Duell]

My understanding is that bug 742174 comment 15 makes it clear HTTPbis specifies we want our current behavior (treat blank Location as redirect to self).