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

HI Justin,

Reading through this I tend to think we agree on most points. Let me  
elaborate here:

On Jun 1, 2008, at 4:19 PM, Justin James wrote:

> My thoughts are fairly clear on this, but I think I have muddled  
> them in
> trying to explain.
>
> * HTML has NO BUSINESS with redirection. End of story. The browser DOM
> allows for the changing of the location property of the browser,  
> which is
> different from the concept of "redirection".
> * Redirection is purely a function of HTTP.
> * As a network protocol, HTTP does not define the *UI* of the UA.
>
> The only reason why HTTP is able to perform a redirection is due to  
> the meta
> http-equiv structure; this structure exists to allow HTML documents to
> contain data that should have been sent as HTTP headers, but the  
> author of
> the HTML document does not have the ability to send those headers if  
> it is a
> static page.
>
> As a side note, any developer sending http-equiv when they have the  
> ability
> to change the HTTP headers in the client-side code most likely  
> should NOT
> be.

I agree for the  most part (I'm looking at you Google), but I must  
admit some web authors may have a reason to do so.  And this proposal  
gives authors that flexibility.

>
>
> Do you know what the REAL problem here is? The REAL problem is NOT  
> that the
> HTML spec needs to define the UI behavior of the UA. The REAL  
> problem is the
> incredibly bad set of specs around http-equiv. What needs to be done  
> is to
> leave this really bad "refresh" mechanism in place for backwards
> compatibility, and provide a full and proper extension of the http- 
> equiv so
> that HTML authors have the ability to specify the full spectrum of  
> HTTP
> status codes that related to redirection.
>
> In other words, instead of HTML specifying the UI behavior of the  
> UA, we
> instead need to do the following:
>
> * Allow authors to use the correct HTTP status (with associated  
> data) to
> keep do redirection, but allow them to use the correct type of  
> redirection.
> * Keep the existing "refresh" for backwards compatibility, and  
> immediately
> mark it as "obsolete".

I totally agree with you here. That's is where the wiki page is  
evolving towards.

> Any UI behavior of the UA is strictly up to the UA implementer on  
> this. It
> is not HTML's job to specify the UI behavior in regards to network  
> protocol
> level behavior. I know that the "H" in "HTML" and "HTTP" are the  
> same thing,
> but I am getting really tired of this group's assumption that HTML  
> is always
> carried over HTTP and delivered to a full-fledged Web browser with a  
> human
> being without special needs who has access to a full sized mouse and
> keyboard.

I agree here too. Part of the use case for providing better meta  
redirection is to provide author with a means for redirection when  
they are not using HTTP.

> HTML is a document standard, first and foremost. Specifying how
> the document reader behaves when encountering a network protocol  
> level event
> is just incorrect. I am sure that the RTF document doesn't discuss  
> how an
> application that reads RTF should behave *if* the document is being  
> read
> over SMB (as opposed to FTP, HTTP, NFS, etc.) and the file server  
> becomes
> unavailable during the file transfer. So why are we discussing the  
> UI's
> behavior in response to a network protocol level event?

The goal here is to discuss the UA’s behavior in response to the meta  
redirection.  I included http redirection headers only to make sure  
that they are handled consistently. Perhaps a better approach to  
writing this would be to make reference to the HTTP RFC and then  
simply direct UAs to handle the two corresponding redirects in a  
consistent fashion (whether from meta or from http headers). So I'm  
not suggesting the UAs need to change their behavior with respect to  
http redirection headers. I'm saying they should make sure they behave  
consistent with these newly proposed meta redirection mechanisms.

Where we may disagree is over additional UA guidance. I see no problem  
— given what this proposal is trying to accomplish — in guiding UAs to  
provide better behavior with respect to redirects (not with MUST or  
MUST not language, but with SHOULD, SHOULD NOT, MAY)

> It is not our concern, even if we are all concerned by it. I agree  
> that the
> way browsers react to redirection is often not very useful, usable,  
> ideal,
> and sometimes leads to the user doing something not secure/safe. But  
> that
> doesn't mean that it is our responsibility (or even within our  
> charter) to
> change that.
>
> And yes, I think most of the other similar portions of the HTML spec  
> are
> similarly flawed. In fact, I think that a significant portion of the  
> HTML 5
> draft has no business being defined in HTML 5, and smacks of scope  
> creep on
> a massive scale. Direct SQL access from HTML is just the tip of the
> iceberg...

I agree on this as well.

Take care,
Rob


> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org]  
> On
> Behalf Of Robert J Burns
> Sent: Sunday, June 01, 2008 8:01 AM
> To: Justin James
> Cc: 'Julian Reschke'; 'Thomas Broyer'; public-html@w3.org
> Subject: 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 Monday, 2 June 2008 11:45:21 UTC