Re: clarify "redirects" in checkpoint 7.5

> (7.5)
> "until user agents provide the ability to stop auto-redirect, do not 
> use markup to redirect pages automatically. Instead, configure the 
> server to perform redirects."

There are many issues to do with hacks used for redirecting without
server side configuration:

1) without content on the page, they can produce the more and more
frequent syndrome of web sites that consist of exactly one page which
is completely empty (scripting unavailable or disabled for policy reasons,
or Refresh on an older browser - although the latter tends to produce sites
consisting of one GIF image, or Flash fanfare);

2) with content, they can result in the content flashing up for long
enough to be noticed but not long enough for someone who takes a long
time to read a page to be sure that the content was not relevant;

3) when implemented using Refresh (NB this is strongly discouraged in
the HTML specification itself, but very common), it results in broken
back buttons - as soon as you hit back you are forced forwards again;

4) when implemented in the most obvious way with scripting, it also
breaks the back button - more recent browsers have an alternative 
method that doesn't break it, but I don't think this existed in the
original browser object models;

5) Status 30x redirects work with essentially any browser and, in theory,
if not in practice, have allowed automatic repair of bookmarks (Favorites
in Microsoft speak) for a very long time.  Status 301 redirects definitely
allow for more effective repair of broken links, when used in combination
with link checker programs - unfortunately, execept for the automatic
redirect to repair URLs with missing final /s, they are very rare.

> I'm working on something where the redirects happen server side, 
> using standard server side coding, rather than configuring the server 

If you generate "Location: xxxx", and possibly "Status: 30x", at the
head of your CGI output (or set the corresponding server object
properties in ASP), I would say that you were compliant.  The
guideline is not intended to be used legalistically.  It is simply
covering the most common case of failing to use the server side
functions, which often arises because people either like a one tool
approach (everything in the HTML document) or are using such cheap
web space that they are not allowed to configure that part of the
server meta-data.

Note that you should not use just Location or use a status of 302 
(or 301) if you are redirecting to confirmation page from a POSTed
form.  A conforming browser (early GUI ones are not conforming) will
try and re-post the form to that URL, and a security conscious browser
will first ask for confirmation.  There is a specific status code
for this purpose.

(As well as 302 responses to POSTs, the other common server side
redirect errors are sending the client a redirect to a custom
"not found" page - it's OK on NCSA, and I think Apache, to use an
internal page, as the redirection is performed locally and the client
sees just the 404 response - and relative URLs that actually get sent
to the client.  The former frustrates link checking programs and the
latter is, in practice, harmless, although a protocol violation.)

> to perform redirects - I'm not totally sure whether this method is 
> within the checkpoint or not.

I'd say that it was well within the spirit; the CGI script is something
that is configuring the server.  They are basically saying use Status
30x/Location, not "Refresh: 0:xxxxx" or location.href = (or even the
slightly better, "location.replace (....)")

Received on Thursday, 7 March 2002 03:27:47 UTC