Re: UA norm for redirects (both META and http)

HI Justin,


On Jun 1, 2008, at 4:52 AM, Justin James wrote:
> Robert –
>
> I think that no matter what, any specs regarding the handling of  
> *any* HTTP
> status codes, redirects, etc. belong in the hands of the folks who  
> work on
> HTTP, not us. And I am fairly certain (based upon the current HTTP  
> spec),
> that specifying UI behavior is well outside of their jurisdiction as  
> well.

I'm not really sure what you're saying here. My reading of what you  
say here is that HTML5 should not specify UA handling of redirects  
because that's HTTP’s job. Then you go on to say that it is not HTTP’s  
job either. So who’s job is it? Others have already quoted the HTTP  
RFC describing UA handling of HTTP redirects. So I'm not sure why it  
is outside their jurisdiction.

On the other hand, the HTTP RFC and WG have no business defining UA  
behavior with regard to the meta element and the http-equiv attribute  
in HTML. That would be our job. My goal with this issues (gleaned from  
earlier conversations around the topic), is to make sure UAs handle  
meta and HTTP 301 redirects in a consistent manner. It would be  
helpful if you could stay focussed on the issue and describe what  
problems could arise from specifying it the way it is or specifying it  
at all.


Take are,
Rob

original message
> From: Robert J Burns [mailto:rob@robburns.com]
> Sent: Friday, May 30, 2008 5:24 AM
> To: Julian Reschke
> Cc: Justin James; 'Thomas Broyer'; public-html@w3.org
> Subject: Re: UA norm for redirects (both META and http)
>
> HI Julian, Justin and Thomas,
>
> On May 30, 2008, at 7:27 AM, Julian Reschke wrote:
>
>
>
> Justin James wrote:
>
> The issues that the original request attempts to address, in terms  
> of how
> browsers handle the redirect. Basically, my suspicion is that  
> application
> developers don't realize that multiple HTTP status codes can produce a
> redirect, and they may have a redirect reason or two that the existing
> status codes don't cover. What I see is that developers tend to use  
> 302
> (Moved) which is rarely the correct status code for what they are  
> trying to
> accomplish. So between developers frequently operating in a state of
> ignorance, and the HTTP spec not fully meeting their needs (although
> experience shows that few would use the needed feature if they were  
> added
> anyways), we have a scenario where the browser's behavior is often not
> ideal.
>
> That may all be true, but I'm not sure how this is HTTP's problem.
>
> HTTP basically distinguishes "moved temporarily" and "moved  
> permanently".
> Are you looking for more detail? What? And what would a UA do with it?
>
> Thanks for the input on this. I changed the wiki page[1] so that it  
> only
> concerns 301 (permanently moved) redirects[2]. The motivation behind  
> the
> proposal is to advise UAs to treat the 301s and the META redirect
> consistently and in an interoperable manner that authors (and users)  
> can
> count on.
>
> On the issue of authoring misuse of 301s, is there some other litmus  
> test we
> can apply (such as consistent response headers) that could help  
> identify
> these misused 301s? If not, my inclination would be to simply treat  
> all of
> the 301s the same along with 0 timeout META redirects (with perhaps  
> the
> exception of handling some differences for extended redirect  
> timeouts, as
> Boris suggested).
>
> Take care,
> Rob
>
> [1]  <http://esw.w3.org/topic/HTML/RedirectNorm>
> [1]: <HTTP/1.1 section 10.3 Redirection 3xx>
>

Received on Sunday, 1 June 2008 12:01:36 UTC