Re: #364 Capturing more information in the method registry

Amos, I'd say that the caching semantics of any non-GET method are going to be subtle enough where you'll really need to read the spec. Furthermore, I'd be surprised if any more cacheable methods are defined (the WebDAV people seem to have settled down).

While it's true that the registry might give you a cheap discovery mechanism for finding new cacheable methods, I'd think a better indication would be user demand...

Cheers,


On 04/07/2012, at 9:10 AM, Amos Jeffries wrote:

> On 03.07.2012 19:28, Julian Reschke wrote:
>> On 2012-07-03 04:24, mike amundsen wrote:
>>> +1 on listing idempotent. this is _critical_ in assessing the use/impact
>>> of a method. I'm not clear why it's left off the listing.
>>> ...
>> 
>> Anything in the registry beyond the pointer to the defining
>> specification is just a shortcut; just because it's not in the
>> registry doesn't mean it's not there.
>> 
>> Adding new fields is possible, but we need find a balance; also, it
>> requires deciding on the value for all methods in the list, which also
>> doesn't come at zero cost :-)
>> 
>> Best regards, Julian
> 
> 
> FYI: I made that comment at the point of writing a parser to handle methods.
> 
> Having just read may way through 2 WebDAV and 2 HTTP RFC and re-read the HTTPbis drafts, your post came as a bit of a non-surprise to find there were more RFCs which I now have to read just to find out if the methods listed are idempotent and/or cacheable.
> 
> Having a quick reference safe=yes/no, idempotent=yes/no would greatly assist writing parser that treated these methods as safe or idempotent without having to read/support every RFC on the block.
> 
> An indication of cacheability would also be great, yes/no/conditional kind of thing. Something to indicate if we proxy authors actually have to read the RFCs in question for correct interoperable behaviour when handling the method. Otherwise the method is going to get left on the "other" pile and not be supported fro a longer time. Which is a shame for new cacheable method responses.
> 
> 
> Just the core considerations requested for new methods. Since those are the details we have already as a WG identified as important/critical for HTTP software implementing the method to be aware of.
> 
> AYJ
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 3 July 2012 23:40:49 UTC