Re: HTTP Methods

On Feb 26, 2004, at 15:26, ext Seaborne, Andy wrote:

> ...
> 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.

I considered this approach at length in Cannes and ended up rejecting
it for two primary reasons: (1) is pushes implementational complexity
onto the client, which is inefficient both in terms of processing and
implementational effort, given the usual ratio of clients to servers,
and (2) it would be more efficient to simply return the URI of a portal
via which the authoritative description could be obtained, with the
protocol(s) required to interact with that portal defined by a standard
such as is expected to arise from the DAWG work.

>
> 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).

I've actually been talking to Sun about that, and hope to see the SDK
allow arbitrary methods in the not-too-distant future (probably still
throwing an exception but setting the method as a side effect).

> 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.
>

Then I will continue to labor on...

Cheers,

Patrick


> 	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
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Monday, 8 March 2004 08:08:45 UTC