Re: deployment issues with fragment/range protocol

On Thu, 15 Jul 2004, Alberto Reggiori wrote:

I'd make that:

> http://a9.com/display?id=foobar

versus

> http://a9.com/display/foobar

to match the cases we've found in the wild/have bitten us.

Essentially we see opportunistic caching products use heuristics such as
detecting a '?' query fragment and in some extreme cases the presense of
the substring /cgi-bin/ to assess the cachebility of a response;  rather
than do the right thing and rely on get-if-modified; Expire and other
decent headers.

Given the historic use of ?, the lack of Last Modified, Epxired headers,
and that RFC 2396 indicates that the query component is a string of
information to be interpreted by the resource combined with the fact that
BaseURI algorithm simply appends the query one an not entirely blame the
cache authors.

But I'd be very aware of these implicit and explicit semantics and
certainly suggest that:

> http://rest.myorg.org/#xpointer=xmlns(ns:=http://myorg.org/xpointer/
> scheme/xpath)ns:xpath(//item/3)
...
> I prefer to use ? (or / or whatever, but not #) to join the
> query to the rest of the URI, so that our design would say
> the URI in this case is:

IMHO the choise between ?, / and # is NOT an equal one. '#' seems wrong;
this is not a fragment(*); / carries local path semantics and ? is too
close to 'beeing interpreted by the resource' rathern than be a resource
in its own right. If you see the URI as a URI in its own right then
perhaps you should treat it as a path segement with parameters (i.e. use
the ';') as these are not significant when parsing relative references or
ubset caching heuristics nearly as much.

Dw.

*: and the # URI cannot be carried over standard HTTP as easily; as you'd
   need to trick standartd fetchers in -not- stripping it off before it
   goes over the wire.

Received on Thursday, 15 July 2004 04:12:12 UTC