W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2003

Re: Redirection

From: David Woolley <david@djwhome.demon.co.uk>
Date: Tue, 11 Nov 2003 07:41:00 +0000 (GMT)
Message-Id: <200311110741.hAB7f0n17655@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org

> database and generated 'on-the-fly'.  These documents were all accessed 
> from a single URI, with the query string selecting the document.

These are not one URI, they are multiple URIs.  However, if the pages
are really static pages accessed with something like ?linkid=9999,
you do not need the question mark with any good web server.

> To enable Google to index the material, the documents are being 
> re-created as HTML documents rather than dynamic ones.  The original URI 
> will still provide the listings (and metadata), but the links will be to 
> the new HTML documents.

As already indicated, Google will already index anything accessed with
a GET method, at least without cookies.  (Given the abuse of cookies
for click trailing, I would rather hope that it will actually index
links from pages that do set cookies as long as the response doesn't
require the cookie.)

> The problem, as I see it, is that calling the URI with the old 'display 
> document' query string will no longer work since the document content 
> will no longer be stored in the database.

I got lost at this point.

> Would it be acceptable to send an HTTP 301 code from the programme to 
> redirect the user agent to new document location (the HTML file)?

HTTP redirects are always acceptable, however status 301 redirects are
an invitation to update bookmarks etc., even if rarely if ever implemented;
if you can reasonably send a 301 redirect, you should send the static
link in the first place.  Status 302 may be more appropriate.  (If
HTTP redirects were not acceptable, people would fail to get documents
if they missed the final / of a directory URL, as on typical servers,
these result in a status 301 redirect to the proper URL, with the /.
HTTP Redirects have much wider support that HTTP Refresh.

> I appreciate that the Guidelines don't like META element redirects, but 
> what about this technique?

This, much ignored, prohibition is in the HTML specification itself
(SHOULD NOT level if I remember correctly).  Note that, whilst you
should still not use it for redirects, if you can generate proper 
redirects, you can also send the Netscape server side "push" Refresh
header as a real HTTP header and it will be accepted by browsers
that would accept it in meta.

> I don't see how this could constitute an accessibility problem unless 
> the user agent were unable to process a 301, but then is every UA fully 
> aware of every HTTP code?

Not every user agent is aware of all codes, but all should treat
301 and 302 as redirects.

Note that, if you do generate apparent form pages that are logically
static and cookie free, you should explicitly set both Expires and
Cache-Control HTTP headers to indicate a reasonable lifetime.  Public
caches inhibit expiry time heuristics on URLs containing ? becuase
of past abuses.  Two GETs reasonably close together should not result
in significantly different editorial content being returned (a weather
recording system may return the actual temperature, of course).

PS.  Please try to use more specific subjects; one spammer technique
is to use single word subjects because it is difficult to judge
whether they are legitimate or not.
Received on Tuesday, 11 November 2003 02:51:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:26 UTC