W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

Re: Refresh and redirects

From: Al Gilman <asgilman@iamdigex.net>
Date: Tue, 29 Feb 2000 18:23:22 -0500
Message-Id: <200002292322.SAA146542@smtp1.mail.iamworld.net>
To: w3c-wai-ua@w3.org
AG::

Here is how I would interpret that language.  Hope this helps.

ND::

At 03:13 PM 2000-02-29 -0500, Nir Dagan wrote:
>There are some unclear issues with the 
>Refresh HTTP header/ Meta tag in the techniques document
>http://www.w3.org/TR/2000/WD-UAAG10-TECHS-20000128/
>article 3.8
>
>First I do not know what you mean by 
>"server-side redirects". All redirects I know of are client side:
>
>1. The server returning a response with a 3xx status code, and the client 
>issues another request to the URI indicated in the location header.
>

AG::

Please consider "server-side redirects" to refer to this case.
"Server-side" in this case because the server has to know something to make
the redirection happen.  It happens on the server side of the user agent,
without parsing any document content beyond the headers communicated
between the HTTP implementations in client and server.  If redirection only
is desired, the server should use 3xx and not a Refresh header, no?

ND::

>2. The server returning a response with a 200 status code and a Refresh
header,
>and the client issues another request to the URI specified in the Refresh
header.
>
>3. The server returning a response with a 200 status code and an 
>enclosed HTML document with a meta tag imitating the Refresh header 
>as in 2. above, and the client issues another request to the URI 
>specified in the meta tag.
>

AG::

The third case is what I would expect is meant by "client-side"
redirection, i.e. from within the document without touching HTTP headers.

ND::

>Refresh and status 3xx have several differences:
>1. Refresh may have a time delay suggestion
>2. Refresh may refer to the same URI of the response. 3xx should not.
>In RFC2616 "10.3 Redirection 3xx" we find:
>"A client SHOULD detect infinite redirection loops, since such loops 
>generate network traffic for each redirection."
>3. Refresh is not a part of any HTTP specification. Its specification is 
>given by Netscape's in:
>http://home.netscape.com/assist/net_sites/pushpull.html
>
>The statement "Instead of this markup, authors should use server-side 
>redirects (with HTTP)." doesn't make sense since 
>1. "server-side redirect" is not defined.

AG::

See interpretation above.  I don't object to having the doucument language
tightened to say technically correct things, though.

ND::

>2. The markup example is of redirecting to the same page with a 
>   time delay, which is impossible with 3xx status code.

AG::

By all means fix the example.

>3. It is not an advice to user agents, but to content providers.

The suggestion as to content practices is worth noting here, but as a note
with a link to the applicable part of the WCAG.

There are two issues, to me:

One is user control of the implementation of Refresh.  I think that is
covered in checkpoint 3.8 of the UAAG.

The second is the use of Refresh with a delay of zero seconds in a META
element to emulate redirection.  This is a content issue, see WCAG
checkpoints 7.4 and 7.5.

Al

>
>Regards,
>Nir. 
>===================================
>Nir Dagan
>Assistant Professor of Economics
>Brown University 
>Providence, RI
>USA
>
>http://www.nirdagan.com
>mailto:nir@nirdagan.com
>tel:+1-401-863-2145
> 
Received on Tuesday, 29 February 2000 18:22:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:52 GMT