Re: Making MGET more GET-friendly?

Dirk-Willem van Gulik wrote:
>> How about if it was MANDATORY for responses to MGET to have a
> 
> s/MGET/GET/ perhaps ?
> 
>> Content-Location header giving a URL which could be used to retrieve
>> the metadata via GET. 

No, if GET had a Content-Location header it would give the location of 
the *representation*, not the description. However, there could be a 
Metadata-Location header or somesuch. Let's assume this below.

> Now I am _not_ saying that the above is impossible; just that the model
> is more geared towards 1 on 1 relations between data and metadata
> and that it sort of assums very similar access vectors.

I know basically two ways of authenticating a connection to an HTTP 
server: HTTP authentication; and layers "below" HTTP, as in HTTPS, or 
SSH tunnels.

If you have HTTP authentication, before authentication the server 
returns a challenge, which could include the URI of the metadata in its 
headers, so somebody who cannot access the data may be able to access 
the metadata. The other way around, the URI of the metadata can 
obviously have more restrictive access control than the data itself. So 
in this case, I don't see why the Metadata-Location approach would allow 
for less access control.

If you have HTTPS or SSH tunneling, in the MGET case data and metadata 
have the same level of access control, because both use the same type of 
connection to the server.

(Hm, you could configure the server to allow MGET from any host, and GET 
only when the connection goes through some "secured" line. But then, the 
server would return a 403 to a GET from a non-authorized host; this 403 
could include the metadata location; and thus again we could have the 
same access control with Metadata-Location.)

So I don't agree with your argument against this approach, because I 
think it supports the same models for access control that pure MGET 
supports. (Not mentioning of course that David didn't propose to give up 
on MGET, so for clients that can support that it's still available.)

Cheers,
- Benja

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