- From: Justin James <j_james@mindspring.com>
- Date: Thu, 29 May 2008 16:32:19 -0400
- To: "'Thomas Broyer'" <t.broyer@gmail.com>, <public-html@w3.org>
I agree, I believe that the HTTP spec contains the appropriate and needed information on this. The concept of redirection is a network protocol item or a DOM item (note that you don't say browser.redirect(), you simply change the value of the location property!). If this makes life tough for application developers, they need to take that up with the HTTP folks, which is where the problems currently stem from. :) J.Ja -----Original Message----- From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Thomas Broyer Sent: Thursday, May 29, 2008 1:38 PM To: public-html@w3.org Subject: Re: UA norm for redirects (both META and http) On Thu, May 29, 2008 at 3:50 PM, Robert J Burns wrote: > > Dear WG, > > Here is another issue that needs to be introduced here for discussion, as it > will be added to the issue-tracker in time. This issue has been discussed > within the WG previously surrounding accessibility concerns when UAs follow > redirects without updating users and the user's data. I welcome additional > feedback. > > UA norm for redirects (both META and http).[1] "In cases where the original URI is maintained as a bookmark for the user, the UA should either interactively offer to update the bookmark on behalf of the user or do so automatically." No need to do anything, this comes with HTTP right out-of-the-box: if the redirect is a 301, the UA SHOULD update the bookmarks [1], otherwise it SHOULDN'T [2]. [1] "any future references to this resource SHOULD use one of the returned URIs." [2] 302: "Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests" 303: "The new URI is not a substitute reference for the originally requested resource" 307: "Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests" -- Thomas Broyer
Received on Thursday, 29 May 2008 20:33:31 UTC