tor 2008-01-31 klockan 09:55 +1100 skrev Mark Nottingham: > I find this just plain weird. On POST responses, it implies that you > can negotiate for response headers on another resource and get them > tunnelled back in the current response. If there's a Vary header > present, does it apply to that resource too? If not, how do you know > what the requested variant really was? Content-Location, except that you can not blindly trust it due to security implications... and we have already agreed that URIs indicated by Content-Location SHOULD NOT be subject to server driven content negotiation. Layering content negotiation ontop of those quickly leads to recursive madness. > On PUT responses, it's a little more sane, but the language forces the > requested variant to be the same as that just created; i.e., if > there's a chance of conneg, the Accept-* headers have to be set in > lockstep with what you're PUTting. So, you'd better not set Accept- > Encoding: gzip unless the request entity is also content-coded with > gzip, and AFAIK many implementations will have problems here, because > these mechanisms tend to be taken out of developers' hands. It's the same in both as both may create a resource at a location different than the requested URI. Even more obviously so in case of POST than PUT as the request-URI of a POST is a data processing agent.. but the principle on what is the actual created resource location is about the same for both.. Regards Henrik
Received on Tuesday, 5 February 2008 13:22:09 UTC