Re: Restoring PUT and DELETE

On 01/12/2011, at 12:09 PM, Julian Reschke wrote:

> On 2011-12-01 12:03, Cameron Heavon-Jones wrote:
>> Hi Yehuda\Mike\Juilan,
>> 
>> Its good to get back to this issue, hope it keeps the traction this time :)
>> 
>> Without going into too much detail yet, there were two points from the
>> last discussions to be highlighted at this point.
>> 
>> The first is with regards to browser handling of responses. I did some
>> thorough testing of the current state of play of browser behaviour in
>> this area and found that browsers are on the whole up to spec with their
>> behaviour and that the default for content responses is to render
>> whatever payload is returned. I have a matrix of these responses which
>> can be added to any docs [attached].
> 
> That's awesome. I might have some more questions later, but it would be really cool if you could add tests for 299 and 399 (testing for new status codes in existing ranges).

cool, i'll add new status code tests and might split into content\no content tables which might make it a bit more digestible.

> 
>> While performing the browser tests however, i started to doubt the
>> necessity of such tests - perhaps this is a more methodological
>> question, but is the html specification the place for defining http
>> behaviour?
> 
> It's at the intersection between HTML and HTTP. I think it needs to be specified *somewhere*, as it affects:
> 

yes, this isn't directly covered in the http specification. the status code description provides the type of response but the behaviour is up for interpretation which is seen in browsers handling of 3xx redirection codes. on the whole it's not that bad but it would be useful for form use to have some unified behaviour on 304 - not modified.

> - the ability to introduce new status codes and get them processed by UAs (think <http://greenbytes.de/tech/webdav/draft-nottingham-http-new-status-02.html#rfc.section.6>),

the referenced status code and type of interaction for network authentication may already be possible from the proxy returning a content response including a form for capturing user credentials, there might not need to be any agent integration in this case? the default behaviour for 5xx responses is to render the payload.

> 
> - what we can respond to HTTP requests generated by forms, and also

requests from forms should be capable of capturing and defining a complete http request so that server response is driven by the protocol and not deduced from the client. this should be possible if the ability for form requests to define http headers is added which constitute part of a full request representation.

> 
> - how we can deploy new authentication schemes.
> 

i was thinking previously about how http authentication might be integrated within forms but also maybe http CONNECT method may be useful to include and the requests it needs to generate are simpler.

>> The other issue is that specifications for PUT and DELETE are not too
>> held back with conformance for current server implementations. As new
>> functionality to html and hence requiring to be explicitly added by
>> authors there should not be any backward compatibility to break.
> 
> Yes, but then what browsers do with PUT and DELETE (and maybe other methods) should work well with what servers already implement; it would be bad if they would have to special-case their responses for "browsers".
> 
> Best regards, Julian


yes, i agree but the specification should not necessarily be a drop-in html control for webdav :) if forms can integrate with the full http protocol there should be no reason requests from browsers need to be special cased.

thanks,
cam

Received on Friday, 2 December 2011 13:53:39 UTC