Re: Making MGET more GET-friendly?

On Mar 11, 2004, at 15:11, ext Sandro Hawke wrote:

>>> Architecturally, you seem to be advocating making a whole bunch of
>>> very interesting data not addressable by URIs.   Seems like a step
>>> backwards.
>> You have misunderstood me. I'm not advocating not denoting 
>> descriptions
>> with distinct URIs. The Nokia implementation provides a URI for every
>> description.
> How, via a Location header on the response to MGET?   And that
> Location can be accessed via GET to get the same content?
> That seems fine.


>>> I think the extra round-trip is worth the cost,
>> You'll have to back that up with some motivating arguments.
> It's a question of comparison of costs.   Which makes me realize
> there's something I don't understand about MGET: how is my software
> supposed to know whether to use MGET?  Is it supposed to try MGET
> first, see the "501 Method Not Implemented", and then fall back to
> GET?   So there's an extra round-trip for everything *not* served by

You're application would simply not presume that GET is going to
provide a description (as opposed to a representation).

I'm not a proponent of multiple approaches.

I see no logic in first try this, then this, then that other thing,
then this other possibility...

The whole *point* of standards is so that we can avoid such nonsense.

One standardized methodology for accessing resource descriptions
(however inefficient) is better than a half dozen alternatives
that every client has to implement and juggle between.

> Also, is it possible to make a typical Hosting service Apache user
> account answer MGET?   Does it at least get through to CGI?
> [I don't see these questions answered on the URIQA page.  Sorry if I
> missed them.]

You didn't miss them (I've got several things I need to add...)

You can easily provide support for the URIQA methods in any
web service (servlet, CGI, whatever).

Ultimately, though, for economy of implementation effort,
you'd want the root or default service, or the server itself,
to provide support for URIQA methods.

You could also implement URIQA using a proxy, where the actual
web server is behind the proxy and for URIQA requests, the
proxy redirects to a particular service portal (e.g. such
as and all other requests are
passed through unchanged.



Patrick Stickler
Nokia, Finland

Received on Thursday, 11 March 2004 09:44:24 UTC