On Thu, Feb 19, 2009 at 1:18 PM, Noah Slater <[email protected]> wrote: > On Thu, Feb 19, 2009 at 12:58:46PM -0500, Paul Davis wrote: >> You can't just wave your hands and say this particular use of headers >> is a violation of the best practices without making an argument for >> why you don't think the specific headers we use are part of the >> protocol. > > Did you read the essay that I posted? > > HTTP is a transfer protocol, which means that the headers are meant to be > related to the transfer of resource representations, and nothing else. To put > it > another way, the headers are a way of the client and server to negotiate how > to > pass request and response bodies back and forth. >
The essay that I read was mostly concerned with the fact that people are just adding headers willy nilly to the protocol without taking the time to consult the list of standard or proposed headers. Hence why I went through and tried to find the referred to repository. I managed to find a couple different lists, but nothing that felt overly official. If there were already a proposed header that fit our needs I'd be all for using the previously proposed header. >> In my opinion, the X-Couch-Full-Commit header is affecting the >> protocol itself vs the individual request. Consider the Cache-Control >> header. I'd say that the similarities are pretty close. > > The Cache-Control header is a way for the client and server to negotiate with > each other about the nature and status of cached resource representations. > This > is suitably related to the transfer protocol. > The X-Couch-Full-Commit header is a way for the client and server to negotiate with each other about the nature and status of the stored resource representation. This is suitably related to the transfer protocol. >> to dismiss it as only part of the protocol for caching proxies and >> what not, but are we not caching the post body temporarily in the >> absence of X-Couch-Full-Commit? > > CouchDB full commits are a mode of internal operation for the server and have > no > relation to the transfer protocol of resource representations or actual the > exchange of request and response bodies. > This isn't about CouchDB. The argument is about whether a resource representation being guaranteed a level of persistence suitable for the client is or isn't part of the protocol. Seeing as that Cache-Control is making a guarantee that the resource representation is the actual representation stored at the originating server I don't see how you can make an argument that one header is related to the protocol and the other isn't. >> No that I really care that much, but I find it grating when people >> suspend their critical thinking in the face of dogma. > > I'm not happy that you felt the need to randomly insult me. > I apologize if you feel insulted. It wasn't meant as such. I know your knowledge of HTTP and associated topics far exceeds mine, but you can't expect me to just accept an argument based on that alone. > -- > Noah Slater, http://tumbolia.org/nslater > HTH, Paul Davis
