[Web-SIG] Integer status codes.

[Alan Kennedy]

Dear Web-Sig,

Just a datapoint on status codes about J2EE.

J2EE uses integer status codes, with human readable constants available 
in the javax.servlet.http.HttpServletRequest class, which works well.

http://java.sun.com/j2ee/1.4/docs/api/index.html

But I suppose that since WSGI has no classes to hang such constants on, 
it cannot use that tidy approach.

Perhaps an environ variable called "wsgi.status"? Which could be a 
dictionary mapping integers to status strings? E.G. applications would 
write code like this

def handler(environ, start_response):
   start_response(environ['wsgi.status']['FILE_NOT_FOUND'], [] )

Or maybe just a simple object containing integer constants?

def handler(environ, start_response):
   start_response(environ['wsgi.status'].FILE_NOT_FOUND, [] )

I don't think I'd find the management of such a table/mapping that 
onerous. After all, there's only a few tens of status codes, and they 
don't change very often.

And the code to implement it would be universal, i.e. easily copyable 
and pastable. If I can paste it into email, is it that much of a code 
management hassle?

#----------------------------------------
status_to_int = {
  'CONTINUE'                        : 100,
  'SWITCHING_PROTOCOLS'             : 101,
  'OK'                              : 200,
  'CREATED'                         : 201,
  'ACCEPTED'                        : 202,
  'NON_AUTHORITATIVE_INFORMATION'   : 203,
  'NO_CONTENT'                      : 204,
  'RESET_CONTENT'                   : 205,
  'PARTIAL_CONTENT'                 : 206,
  'MULTIPLE_CHOICES'                : 300,
  'MOVED_PERMANENTLY'               : 301,
  'MOVED_TEMPORARILY'               : 302,
  'SEE_OTHER'                       : 303,
  'NOT_MODIFIED'                    : 304,
  'USE_PROXY'                       : 305,
  'TEMPORARY_REDIRECT'              : 307,
  'BAD_REQUEST'                     : 400,
  'UNAUTHORIZED'                    : 401,
  'PAYMENT_REQUIRED'                : 402,
  'FORBIDDEN'                       : 403,
  'NOT_FOUND'                       : 404,
  'METHOD_NOT_ALLOWED'              : 405,
  'NOT_ACCEPTABLE'                  : 406,
  'PROXY_AUTHENTICATION_REQUIRED'   : 407,
  'REQUEST_TIMEOUT'                 : 408,
  'CONFLICT'                        : 409,
  'GONE'                            : 410,
  'LENGTH_REQUIRED'                 : 411,
  'PRECONDITION_FAILED'             : 412,
  'REQUEST_ENTITY_TOO_LARGE'        : 413,
  'REQUEST_URI_TOO_LONG'            : 414,
  'UNSUPPORTED_MEDIA_TYPE'          : 415,
  'REQUESTED_RANGE_NOT_SATISFIABLE' : 416,
  'EXPECTATION_FAILED'              : 417,
  'INTERNAL_SERVER_ERROR'           : 500,
  'NOT_IMPLEMENTED'                 : 501,
  'BAD_GATEWAY'                     : 502,
  'SERVICE_UNAVAILABLE'             : 503,
  'GATEWAY_TIMEOUT'                 : 504,
  'HTTP_VERSION_NOT_SUPPORTED'      : 505,
}
#----------------------------------------

I'm also happy to see things remain as they are. Having a human readable 
version of the code is handy for code self-documentation purposes.

So I suppose it works just as well for authors to write the following 
examples in their own code

start_response("200 Au quay!", [] )
start_response("200 Cool", [] )
start_response("200 That hoopy frood knows where his towel is", [] )

As long as the integer bit actually evaluates to an integer, it wouldn't 
be a problem.

I sort of like the ability to play with these strings: think of the 
(Monty) pythonisms we could use in our middleware!

start_response("404 Defenestrated", [] )
start_response("410 It's pining for the fjords!", [] )
start_response("414 Who are you calling big-nose, big-nose?", [] )
start_response("417 But I thought this was a cheese shop?", [] )

Regards,

Alan.