RE: HTTP Methods

-------- Original Message --------
> From: Patrick.Stickler@nokia.com <>
> Date: 26 February 2004 03:34
> 
> Having to make two requests to get back (typically) the same amount
> of information that a HEAD request would return is inefficient. It makes
> SW agents "second class citizens" of the web because they have to do
> twice as much work to get the information they need to function.

Abstractly, what is required is a way to get from the URI of the resource to
the description.  Ideally, the description would itself have a URI.

The way MGET does this is implicit - by directing a new operation to the
location of the original URL, it is retrieving (a representation of) the
description.  There isn't a URI for the description (of course, the
description or the response could contain one).

One way is to ask other places about the resource of interest.  3rd party
assertions about resource will be useful.  But even without that, it is
still possible to come up with ways that do the mapping from resource URI to
description URI.

The obvious suggestion: do a HEAD (or OPTIONS) operation and have a response
header field.  But that is an extra round trip.  (Aside: The round trip is
most likely to the same server and there is a connection already set up.)

Or is it?  Suppose what is returned in the HEAD response is a rule for
getting from resource URL to description URL.  This rule could apply to this
this resource uniquely or to some wider part of URL-space, such as all URLs
on this server.  So the rule has a transformation from resource URL to
description URL and a scope.  The rule would be cacheable.  All further URLs
in the scope do not require an extra round trip.

There are probably many improvements that could be made but at least we
haven't required new servers versions nor new client toolkits -
java.net.URLConnection in Java's up to 1.5.0 only work with one of the 7
verbs (HttpURLConenction checks the name of the verb).  

The description gets a URI, the extension to 3rd party assertions about the
resource is natural, and, usually, there is no double round trip.  There are
probably other, better ways - but, to me, the case for a new verb is yet not
proven.

	Andy

> 
> Furthermore, while there are some approaches that can work to accomplish
> the equivalent behavior of MGET (albeit requiring multiple requests)
> such 
> approaches break down when considering the behavior of MPUT, and
> MDELETE.
> 
> Regards,
> 
> Patrick
> 
> -----Original Message-----
> From:	www-tag-request@w3.org on behalf of ext Thompson, Bryan B.
> Sent:	Wed 2004-02-25 17:52
> To:	Stickler Patrick (Nokia-TP-MSW/Tampere); 'www-tag-request@w3.org ';
> 'ext Jon Hanna ' 
> Cc:	'Danny Ayers '; 'Joe Gregorio '; 'www-tag@w3.org '
> Subject:	RE: HTTP Methods
> 
> 
> 
> I do see an opportunity for a "well-known" HTTP method for descriptions.
> However, what I like better is to use HEAD to recover a header, e.g.,
> Service-Description-Uri, whose value is the URL of the service
> description. 
> 
> You can then negotiation the description content type separately.
> 
> -bryan
> 
> -----Original Message-----
> From: www-tag-request@w3.org
> To: ext Jon Hanna
> Cc: Danny Ayers; Joe Gregorio; www-tag@w3.org
> Sent: 2/25/2004 8:45 AM
> Subject: Re: HTTP Methods
> 
> 
> 
> On Feb 25, 2004, at 15:28, ext Jon Hanna wrote:
> 
> > 
> > Quoting Patrick Stickler <patrick.stickler@nokia.com>:
> > 
> > > 
> > > 
> > > On Feb 25, 2004, at 12:40, ext Jon Hanna wrote:
> > > 
> > > > 
> > > > ... I remain unconvinced of the case
> > > > for MGET.
> > > 
> > > Can you demonstrate how the equivalent behavior can be
> > > implemented using the existing methods without resulting
> > > in either (a) multiple requests for each single logical
> > > operation or (b) unintended side effects in the case of
> > > misunderstanding between client and server, or (c) efficient
> > > and explicit failure if the request is not understood?
> > 
> > I'll qualify "unconvinced" as meaning "I've only looked at this a tiny
> 
> > bit, and
> > it didn't convince me" as opposed to "I've looked at this a lot and I
> > think it's wrong". It's an uninformed instinct thing.
> > 
> > That said, and given that URIQA is on my list of stuff I want to look
> > at in the near future (but I've been putting it off until after my
> > current paying project) why not GET application/rdf+xml rather than
> > MGETting? 
> 
> What if the resource denoted by the URI has an RDF/XML representation
> yet you don't want the representation of the resource, you want its
> description.
> 
> Content negotation is about selecting between representations.
> 
> While it might be possible to make it work for differentiating
> between representations and descriptions, it precludes the ability
> to select between different encodings of a description and also
> (even if a special MIME type is used for descriptions) does not
> make it possible to ask for descriptions of descriptions as opposed
> to a representation of the description itself.
> 
> Patrick
> 
> 
> > Granted an attempt to do so will result in most servers sending you
> > text/html or whatever and hoping for the best, but you can stop
> > listening after the 
> 
> > headers,
> > it seems an explicit enough failure.
> > 
> > --
> > Jon Hanna
> > <http://www.hackcraft.net/>
> > "...it has been truly said that hackers have even more words for
> > equipment failures than Yiddish has for obnoxious people." -
> > jargon.txt

Received on Thursday, 26 February 2004 09:32:27 UTC