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

HI Justin,

Thanks for the feedback.

On May 29, 2008, at 2:57 PM, Justin James wrote:

> Is it the business of the HTML specification to define the behavior  
> of the
> UA's UI in this manner? I truly hope not. Maybe there are other  
> instances in
> the spec where stuff like this occurs, but this is logically equal  
> to, "UAs
> that maintain a back/forward history must use a left-pointing and a
> right-pointing arrow graphic on the buttons that provide this
> functionality."

HTML5 already has an entire chapter dedicated to guidance for  
browsers. This would simply be one more.

> I do not believe it is the HTML 5 spec's place to dictate to UA  
> developers
> how their UAs react outside of their actions regarding the HTML  
> itself. In
> other words, our place is to tell the UA folks, "when you see this,  
> perform
> a redirect". It is not our place to tell them, "when you perform a  
> redirect,
> you must let the user know."

I wouldn't advocate this as a requirement level norm, but I don't see  
anything wrong with advising interactive UAs what HTML needs to work  
effectively. Right now (with HTML4) we’re advising authors to not use  
meta redirects in order to prioritize users needs over authors needs  
(some authors only have meta redirects available for redirects). By  
instead following a more intelligent separation of concerns, we can  
provide advice to interactive UAs to let them know what users need to  
effectively use the data provided by authors. Eventually, we could  
then drop the advice to HTML authors to not use meta redirects.

> Aside from all of that, it is an extraordinarily problematic proposal
> regardless; I think of all of the Web apps that would break because  
> the
> author never coded that page that performed the redirect to tag it  
> with a
> unique request ID in the GET/POST data, and by putting it into the  
> browser
> history, make it possible for the user to re-request the page  
> without a full
> re-submission from the original form, causing potential havoc. Not to
> mention the general undesirability of clogging the browser history  
> with a
> million and one redirects. I bet that about 5% - 10% of my  
> interactions with
> my Web browser result in a redirect, thanks to form submission pages  
> that do
> a post-processing redirect so that "Refresh" does not repost the  
> data and
> therefore double bill/post/whatever. Adding all of those  
> intermediaries to
> the history seems like a train wreck to me.

Those are certainly some valid concerns. Perhaps there’s some way we  
can differentiate a certain class of http redirects that we would want  
interactive UAs to track: those most closely substituting for static  
page meta redirects. To clarify, this issue was originally raised  
specifically related to meta redirects. My reason for including http  
redirect is that the same issues apply for some http redirect  
situations. Do you think there are any reliable http response headers  
or status codes that we could use to differentiate the meta-redirect- 
like http redirects from the app server type redirects you're  
concerned about?

Take care,
Rob

Received on Thursday, 29 May 2008 15:28:02 UTC