Re: #364 Capturing more information in the method registry

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

Received on Tuesday, 3 July 2012 23:11:02 UTC