Re: HTTP Methods

On Mar 09, 2004, at 12:45, ext Dirk-Willem van Gulik wrote:

>
> --DS-5024760632041367167
>
>
> On Mar 9, 2004, at 11:39 AM, Patrick Stickler wrote:
>
>> On Mar 09, 2004, at 12:31, ext Dirk-Willem van Gulik wrote:
>>> On Mar 9, 2004, at 11:21 AM, Patrick Stickler wrote:
>>>> On Mar 09, 2004, at 12:05, ext Dirk-Willem van Gulik wrote:
>>>>> On Mar 9, 2004, at 10:37 AM, Patrick Stickler wrote:
>>>>>
>>>>>> URIQA imposes *no* modifications to existing HTTP clients. All 
>>>>>> enhancments are
>>>>>>
>>>>> I must be missing something fundamental. HOW does the client, who 
>>>>> needs data
>>>>> -about- the URL, i.e. the RDF, fetch that data ?
>>> ..
>>>> If that client wanted a description of the resource denoted by the
>>>> URI http://example.com/foo, it would submit a request
>>>>
>>>>    MGET /foo HTTP/1.1
>>>>    Host: example.com
>>>>
>>>> Note that the only difference is the method used, and specifying
>>>> the request method is part of the core HTTP client architecture.
>>>
>>> Ok -- so the client MUST be modified in that case - i.e. on needs
>>> to add code to do 'MGET' instead of 'GET' if the client wanted a
>>> description of the resource denoted by the URL.
>>
>> I think we are talking about different levels of "modification".
>>
> Sure - I just wanted to get things 'right' - as I mention in the 
> summary
> document similar 'changes' which really amount to looking for
> a header or fishing out some URL for the other options.
>
> One of the big advantages of the MGET change is that there
> no change of semantics; totally orthogonal way of signalling
> that you want metadata while -everything- else is kept the same;
> just an extra 'if' and 'MGET' in your code which formulates
> the HTTP request next to the 'GET' you already have.

Right. And one can use standard web techniques such as for conneg,
authentication, etc. (though there does seem to be some work still
to be done regarding proxies and caches to optimize use of URIQA).

Another nice advantage, and one that I plan to implement soon, is that
one need not update every web server in a network subdomain to natively
support URIQA, but one can create/update a proxy server to monitor
for URIQA requests and redirect them to a centralized knowledge
portal, via which descriptions of resources with URIs grounded in
that domain can be accessed.

This is really just a generalization from the server level to the proxy
level of the way things are done in the present URIQA implementation 
used
within Nokia.

Cheers,

Patrick

--

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

Received on Tuesday, 9 March 2004 06:29:17 UTC