Re: Making MGET more GET-friendly?

> > If you assume that - and given the above 1:1; would it not be simpler 
> > to simply
> > postulate an extra header:
> >
> > 	Characteristics-Location: http://www.example.com/ex.rdf
> >
> > in the reply of any GET ? In particular that of the GET of 
> > http://www.example.com/ex.
> > And making sure you -also- get it when a cheaper HEAD is done ? Or 
> > does that
> > not accomplish all you want ?
> 
> No. It doesn't (for me). Please see the URIQA FAQ about the shortcomings
> of the header approach...

It says:

>    Why not first use a HEAD request to get another URI via which the
>    description can be accessed?
>
>           Firstly, this requires an agent to make two requests to the
>           server, rather than just one, which is inherently
>           inefficient. Secondly, while each description is a resource
>           in its own right and can be denoted by a distinct URI, it
>           is seldom necessary to give descriptions distinct identity
>           and therefore unnecessarily burdensome to require that
>           every description of every resource be given an explicit
>           URI simply in order to be able to access a resource's

I agree the round trip is a cost; I see no evidence to support your
argument "it is seldom necessary to give descriptions distinct
identity...".    I need to do it all the time.

Architecturally, you seem to be advocating making a whole bunch of
very interesting data not addressable by URIs.   Seems like a step
backwards.

I think the extra round-trip is worth the cost, and advocate a
"Metadata-Location" header for information resources, and also a "303
See Other" redirect for non-information resources (eg cars, dogs, the
Sun), to get browsers to do the right thing while maintaining strict
semantic distinctions.

     -- sandro

Received on Wednesday, 10 March 2004 09:03:32 UTC