<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [Web-SIG] Internal redirect using Location with absolute pathand status of 200.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Graham Dumpleton wrote:<BR>
> The problem then as above is what does one do at<BR>
> the boundary between a WSGI application and the<BR>
> web server hosting it? Do you just always assume<BR>
> a WSGI application provides an error page, or allow<BR>
> some way that a WSGI application can defer to the<BR>
> web server the task of generating an error page<BR>
> instead?<BR>
<BR>
The web server should not be trying to correct what<BR>
the application gives it, except as absolutely necessary<BR>
to get the response on the wire, or obey the HTTP spec<BR>
(and even that's questionable). If you want consistent<BR>
error pages across an entire application or site, write<BR>
a piece of WSGI middleware which does that and explicitly<BR>
include it in your middleware graph.<BR>
<BR>
To quote the PEP:<BR>
<BR>
In general, servers and gateways should "play dumb"<BR>
and allow the application complete control over its output.<BR>
They should only make changes that do not alter the<BR>
effective semantics of the application's response.<BR>
It is always possible for the application developer<BR>
to add middleware components to supply additional<BR>
features, so server/gateway developers should be<BR>
conservative in their implementation. In a sense,<BR>
a server should consider itself to be like an HTTP<BR>
"gateway server", with the application being an<BR>
HTTP "origin server". (See RFC 2616, section 1.3,<BR>
for the definition of these terms.)<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org</FONT>
</P>
</BODY>
</HTML>