HTTP 0.9 and peeking at URLs
Tim Berners-Lee <timbl@www3.cern.ch>
Date: Mon, 6 Sep 93 11:15:47 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9309060915.AA04008@www3.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: HTTP 0.9 and peeking at URLs
Reply-To: timbl@nxoc01.cern.ch
Status: RO
Jo was saying that libwww HTTP.c should be changed to look at the
URL for HTTP0.9 replies and I objected as it was a violation
of the spec which would cause real problems.
>Theoretically, it shouldn't break anything that uses proper
HTTP/1.0.
>The use of the suffix to determine file type occurs only if it
doesn't
>get a proper HTTP/1.0 response. If it gets a HTTP/1.0 response then
>the code should ignore the suffix.
But it will break HTTP/0.9 which specifies that the returned
files at always HTML or plain text preceded by <PLAINTEXT>.
And specifies taht the url is opaque.
Consider the entry in a gatewayed database
http://.../amc56.figu.88.04.gif
where the end gif in fact stands for "Group d'Interfaces
Foncionelles" and is a database partition. The text comming back
is
GIF8756 is the interface module responable for the interface
monitoring of the valve closure pressure release mechanisms.
It is currently
<PRE>
ON
</PRE>
Sounds contrived but there is a valid server converting valid
url into valid documet, which would screw a clientwhich
looked at the .gif or one which looked at teh first 5 charcters.
So what do we do? I think there will in fact be servers
especially gateways which will fall into some trap like
this, as the gateways are allowed to generate the URL
any way they please. We can't say "but not use dots"
at this stage. And we can't enforce that gateways use HTTP1.0
because the ability to make a script gateway trivially is
really neat.
The only client I think which uses this behaviour is XMosaic
which will be HTTP 1/.0 compliant soon. Servers with graphics will
have to use HTTP 1.0. Noddy gateways to databases will still
be able to use HTTP 0.9.
Tim