- From: Justin James <j_james@mindspring.com>
- Date: Sun, 1 Jun 2008 12:19:23 -0400
- To: "'Robert J Burns'" <rob@robburns.com>
- Cc: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Thomas Broyer'" <t.broyer@gmail.com>, <public-html@w3.org>
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