[Web-SIG] Request and Response objects

[Steve Holden]

[Ian Bicking]
> On Nov 5, 2003, at 10:34 AM, Gregory (Grisha) Trubetskoy wrote:
> > On Wed, 5 Nov 2003, Stuart Bishop wrote:
> >> The "response"-type class is the interesting bit - the API
> for setting
> >> status codes, headers, cookies etc. And you do want multiples, of
> >> which only one is sent to the client. In particular, if
> you catch an
> >> exception and are preparing an error message you will want a clean
> >> response to work with rather than, for example, accidently sending
> >> your error message with the wrong content-type. The
> alternative would
> >> be a reset() method on the response buffer, although this isn't as
> >> flexible.
> >>
> >> def handler(request):
> >> 	try:
> >> 		response = Reponse(request)
> >> 		filename = response.request.getFirst('filename')
> >> 		response.headers['Content-Type'] = 'image/jpeg'
> >> 		response.cookies['latest'] = filename
> >> 		response.write(open(filename,'rb').read()) # A
> filelike object
> >> 	except IOError:
> >> 		response = Response(request)
> >> 		response.status = 404
> >> 		print >> response, 'File not found'
> >> 	response.close() # No more data - compute content-length header
> >> 	response.send() # Send to client.
> >
> >
> > The functional equivalent of the above would look like this in
> > mod_python.
> >
> > def handler(req):
> >
> > 	req.content_type = 'image/jpeg'
> >
> > 	try:
> > 		req.sendfile(req.filename)
> > 	except IOError:
> > 		return apache.HTTP_NOT_FOUND
> >
> > 	return apache.OK
> >
> >
> > 1. This is a pretty good example of the fact that dual
> objects don't do
> > much other than introduce extra typing.
>
> Dual objects avoid something like "req.content_type = 'image/jpeg'",
> which is not just a misnomer, but confusing and ambiguous,
> because both
> request and response have a content type.
>
But in mod_python a request had both headers_in and headers_out, so the
confusion is less. There's also err_headers_out, used only when an error
occurs.

For some reason Apache special-cases the Content-Type header. It's a bit
perverse to suggest we might achieve anything sensible by changing the
_request_ Content-Type, though, or am I missing the point?

> > 2. This is too low level of an example:
> >
> > The specifics of how an HTTP error is handled are going to vary from
> > server to server - e.g. Apache httpd will furnish it's own
> error text.
> > (BTW, HTTP errors shouldn't happen if your application is written
> > well.)
>
> Of course applications should return errors.  404 is common, 401 and
> 403 are entirely reasonable, and 400 is a reasonable way to
> respond to
> unexpected input; 30x errors are obviously okay, and fit into an
> overall framework of exceptions.  And WebDAV servers have to set the
> error response very specifically, including the body of the response.
>
> A boilerplate message is fine when nothing else is specified,
> but there
> should exist the possibility of setting the message in your
> application.
>
I agree it's desirable to have control over error handling, to the
extent of providing a tailor-made page with the application's
look-and-feel where appropriate. Errors will always occur, but the fact
that it's a 404 is irrelevant to many users, and meaningless to even
more. Sensible error messages would be better.

[...]
>
> > Whatever we come up with needs to be at a higher level.
>
> > having flush() would be appropriate I think.
> >
> > sendfile() is another nice thing to have - if the environment has a
> > native implementation (e.g. mod_python), then it could be used,
> > otherwise
> > it'd just be req.write(open(file)read())
>
> Yes, that's a good idea to have.
>
Clearly a good idea to optimize the satic content case!

regards
--
Steve Holden          +1 703 278 8281        http://www.holdenweb.com/
Improve the Internet           http://vancouver-webpages.com/CacheNow/
Python Web Programming                http://pydish.holdenweb.com/pwp/
Interview with GvR August 14, 2003       http://www.onlamp.com/python/