On Mon, Oct 23, 2000 at 01:36:51PM +0000, Lex Spoon wrote:
> Incidentally, Bolot, watch out for using HTTP/1.1 extensions if the
> client identifies itself as speaking HTTP/1.0. A great way to test
> for this case is to use Scamper. :)
>
Yes, this is a very important issue. We'll need to come up with a
fairly clean way to adapt the protocol to whatever the client is
expecting, without having things like Http11Request, Http10Cookie,
etc. Most of the things can be taken care of fairly uniformly (e.g.
reading HTTP/ 0.9, 1.0, and 1.1 headers), whereas others require a
more flexible approach (e.g., returning multiple chunks).
Here's a possible 'proposal':
- implement the protocol support (per RFCs, as close as possible)
(I'm omitting some details for this section)
- detect protocol version of the client request
-- check the client against a list of 'special' cases
(i.e., when a client is known to behave unexpectedly)
Client detection in this case would be a separate issue from detecting
a client for the purpose of identifying its other capabilities, such
as client-side scriptability, support for plug-ins, frames, etc.,
which are more of application developer issues (and they would be
provided to the app developers as widgets).
One example: behavior wrt redirections. Depending on the client, we
could provide the redirection mechanism that would make the client
appear to act correctly (when possible).
Bolot
