zope.publisher returns 200 Ok instead of 200 OK
Hi there, In zope.publisher.http, the status string for 200 is defined to be 'Ok', instead of 'OK', which is in the HTTP spec. Now status messages may, according to the spec, be replaced by 'local equivalents' without affecting the protocol, and the status messages in the spec are just examples. Still, it's a difference without a good reason. Changing this to 'OK' has some impact: particularly tests which verify the status string (which I'm currently writing) will break. Then again, thats' an easy fix. What do people think? Should this be fixed? Regarsd, Martijn
On Nov 13, 2007 9:33 PM, Martijn Faassen <faassen@startifact.com> wrote:
In zope.publisher.http, the status string for 200 is defined to be 'Ok', instead of 'OK', which is in the HTTP spec. Now status messages may, according to the spec, be replaced by 'local equivalents' without affecting the protocol, and the status messages in the spec are just examples. Still, it's a difference without a good reason.
Changing this to 'OK' has some impact: particularly tests which verify the status string (which I'm currently writing) will break. Then again, thats' an easy fix.
What do people think? Should this be fixed?
This came up before in a bug report on Launchpad, and it was decided that to change this would break too much code relying on the spelling of the response. Such code would be wrong, but there was not enough reason to break things. See https://bugs.launchpad.net/zope3/+bug/112109 -- Martijn Pieters
Hi there, On Nov 13, 2007 9:45 PM, Martijn Pieters <mj@zopatista.com> wrote:
On Nov 13, 2007 9:33 PM, Martijn Faassen <faassen@startifact.com> wrote: [snip]
What do people think? Should this be fixed?
This came up before in a bug report on Launchpad, and it was decided that to change this would break too much code relying on the spelling of the response. Such code would be wrong, but there was not enough reason to break things.
Ah, I should've checked launchpad before reporting it. The discussion there is quite clear. Thanks! Regards, Martijn
participants (2)
-
Martijn Faassen -
Martijn Pieters