server parsing of URI path parameters

I've been looking at use of parameters on path segments of URIs, as
discussed in RFC2396 (section 3.3).

As I understand it, the original reason that parameters were used, and
therefore the semicolon was a reserved character, is pre-HTTP/1.1 range
specification. I'm not clear on their current use, and was a bit surprised
to see 2396 say that each path segment could have its own parameters, so
that you could get:
  http://www.foo.com/bar;a=1;b=2/baz/bat.gif;g=5
and so forth. If anyone could clear up the history here, I'd be grateful.

With that in mind, a more HTTP-specific question:
How should an origin server treat a request that includes parameters? Some
trival testing suggests that current practice is to treat them as part of
the path, so that an error is returned. Would it be better to have them
ignore parameters that aren't understood? 

I suspect the answer depends on the purpose and uses of parameters, but I'm
interested to get some views on this.

Thanks,

-- 
Mark Nottingham, Melbourne Australia 
http://www.mnot.net/

Received on Wednesday, 29 December 1999 15:09:50 UTC