httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <hart...@ooo.lanl.gov>
Subject Re: apache-0.2...
Date Wed, 22 Mar 1995 13:36:41 GMT
> 
> B39_CRLF*.txt: Fix header output format to use CRLF not just LF: -1
> 
> You all know that I don't agree with the approach; I think Roy made
> the best point, that the CGI spec allows LF or CRLF, whereas HTTP
> only allows CRLF, and so httpd should do the necessary protocol conversion.

Can I suggest you put that objection aside for now. The patch improves
things, making it conform more to the spec. Later, you can propose a 
subsequent patch which addresses the LF/CRLF debate on script output.

> But this particular patch gets -1 either way:
>  * the patch introduces a bug: a CGI script that sends a Status: header
>    ending in CRLF causes httpd to send a status line ending in CRCRLF
> , and

I just tried both types of Status: line terminator..

CRLF  and LF

Both came out as CRLF, since apache reads the status code and
status message, and saves them for later output, always with CRLF

The patch also ensures that the end of header is marked with CRLF

I can't see how you can get CRCRLF

>  * Either it should add the CR, in which case it is wrong.
>    Or, it should allow the (non nph-) CGI script to send its ouput
>    unchanged, in which case:
>    the patch does not fix a bug in httpd which sets the first character
>    to be a ':' in any CGI header that does not contain a ':'. Such headers
>    are allowed by http/1.0.

If this is a httpd 1.3 problem, then one shouldn't veto a patch which
doesn't claim to fix it when it doesn't.

> B40_trailing_slash.txt:  fix for introduced bug with trailing / in env var: -1
> Sorry, it doesn't work. I now don't get any PATH_INFO data at all in my
> /cgi-bin scripts. In fact, I'd like to retrospectively give a -1 to
> B23 (addtype bug), and have it removed from 0.2...

Works just fine in my code - which uses PATH_INFO heavily.

> E37.load_cutoff.txt: Allow connections to be rejected if high load av: 0
> I think this is rather like the mmap nscache; a bit too unportable.
> You would want to at least try and port it to as many architectures
> first.
> 
> How strongly is this feature needed? I can imagine that it would be
> useful for a non-forking server, but I would have thought that the apache
> at present would be self-throttling.

Far from it. The server at Cardiff, running the movie database sometimes
gets into self destructive mode when the load creeps up - I've seen it
go past 100 - at which point all requests take an age to process and often
the timeout setting means that lots of hard work gets killed.
Setting a cutoff load of say 15, would save on a hell of a lot of 
requests yielding nothing more than a "timed out" message. The user would
instead see a message indicating the current load and the cutoff point.

See http://ooo.lanl.gov/cgi-bin/raise_load

if you haven't already. (please only try it once  :-)

It raises the load on my machine above the cutoff point, and redirects
to another page - so once you see the message, hit reload.

> I would also rather not add a new httpd specific source file for this.
> i.e. I don't think this should be in http_load.c, but in load.c.
> (My test for whether code should be http_xxx.c or xxx.c is whether or
> not it includes httpd.h)
> It is very system specific, and only needs httpd.h for die(); it could
> return an error code instead.

Whatever; we can tidy up prior to any release.



rob

Mime
View raw message