Re: issue 325: When are Location's semantics triggered?, was: Protocols/APIs and redirects

Hi Mark et al,

On 14/12/2011, at 4:47 AM, Mark Nottingham wrote:

> Do we have agreement that a 3xx + Location can / should trigger an automatic redirect (taking into account user notification -- a separate issue)?
> 

If i may provide some observations wrt browser clients and the tests performed to determine the current state of interpretation of http spec and resulting implementation of response handling.

The most interesting aspect for me was the difference between content vs no-content responses. This is the area of greatest complementary implementation behaviour across vendors, and for good reason.

The behaviour of a client in response to redirection codes should not be specified in http as this is dependant on the type of client and its role and responsibly for the end user.

In the case of a browser, the end user is the decision maker and overarching authority over the request and response. for this reason, i believe current behaviour exhibited by *all* implementations is the natural, and correct, behaviour - if content is supplied in response body, terminate any further processing and render the content for the end user to make a decision. 

this provides the mechanism for severs to return the appropriate response status but also to over-ride any automatic handling with the ability to provide custom content describing the nature of the response and any further actions that may optionally be followed and with full description of how or why in rendered media format. possibly this addresses the separate issue of user notification?

the case of what should be default behaviour for 3xx without content or for non-interactive clients is more nuanced. safari has chosen to implement automatic redirects, no doubt from apple's philosophy on interface interaction which is seen throughout their products.

my personal take is that as we already have redirection codes which are automatically followed, to apply as a default for new status codes doesn't really achieve anything we don't already have, yet as noted, an automatic following of redirection may limit future specification and diverges from all other default behaviour which tends to be - if you don't know what it is, don't do anything.

as a member of HTML WG and through working through specifying additional methods on forms, the handling of responses by browsers has been highlighted as an area requiring attention, and potential specification. given that XHR specification includes response handling behaviour, html spec would also seem to be the place for specifying this in the case of rendered html pages. this is currently being looked at under bug 10671 [1].

in the case of XHR, i believe that appropriate callbacks should be sufficient in allowing all use cases to be covered, there are some security concerns regarding cross origin redirection however knowledge of this on the part of the server should be sufficient in the design of these services. I am unsure as to re-applying headers from one request to another on a different domain - the script has setup the appropriate request including custom headers and based on all of this information the server chooses the appropriate response. to start mixing requests sounds a little strange, for scripts an alternative is surely for the server not to return an auto-redirect and instead return the URI and allow the script to setup the appropriate request.

thanks,
Cameron Jones


> Regards,
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
>

Received on Wednesday, 14 December 2011 16:10:30 UTC