perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Chamas <>
Subject RFC on proposed behavior change for $Response->{Status}
Date Sat, 24 Jan 2004 23:03:02 GMT
Hi Apache::ASP Community,

I would like to request your comments on potential changes to
$Response->{Status}.  These potential changes are great enough,
that they might warrant starting a 3.x Apache::ASP release series
because the behavior is so different.


The problem currently is that one cannot set an irregular HTTP Status
line like "404 Not Found Today", where a developer should be able
to use $Response->{Status} to do so.  The problem is that the
$Response->{Status} was being used just to return this status code
to the mod_perl handler phase, say in the case of 404, in which case
Apache would just serve up the 404 ErrorDocument.

The problem I have discovered is that setting a custom status_line()
in mod_perl contradicts returning a status code in the handler phase.
One cannot send custom httpd headers & serve up the Apache ErrorDocument
cleanly, its one or the other.


The fix to this is to handle the status/status_line settings internal
to Apache::ASP, and send back an OK to the Apache handler phase, so that
ErrorDocuments are not triggered for any $Response->{Status}.  So that
means that while before if you set

   $Response->{Status} = 404;

to trigger an Apache ErrorDocument, that would no longer work.  What
would happen instead is that Apache::ASP would output the 404 error
document body itself as usual for 200 Status.  The nice thing is that we
can now output document bodies for any Status code we chose to set and
not worry about the Apache ErrorDocument being used instead.  So one could
have a script like:

   <% $Response->{Status} = "404 Gone Today"; %>
   Gone today !!

and the output would just be "Gone today!!" in the browser.

The only exception to this would be to Status = 500 being set, in which
case this would fall back to the Apache ErrorDocument, as its an
"internal server error" and is likely to be a script or code that
generated a compile time or runtime execution anyway.

My biggest concern is that this will probably break some peoples error
handling as it will currently function, but I believe it is important
to rationalize the way in which Apache::ASP handles custom Status codes
being set at runtime, giving the developer greater control of the
response cycle.

So I would propose therefore that this goes into an Apache::ASP 3.x release
series, so that people would understand that there might be some things that
need to be fixed during such a major upgrade.

Note, that use of ErrorDocuments would still work outside of Apache::ASP
handling a request, for example if a script /path/to/script is not found,
Apache would still serve up the 404 ErrorDocument.  The diffference is when
the $Response->{Status} is generated internally in an Apache::ASP script,
and this will likely not affect many developers anyway in how they current
do things.



Josh Chamas, Founder                   phone:925-552-0128
Chamas Enterprises Inc.      
NodeWorks Link Checker       

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message