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

Robert -

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.

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".

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. 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?

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...

J.Ja

-----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 Sunday, 1 June 2008 16:20:12 UTC