httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: incorrect Allow: header?
Date Mon, 12 May 1997 19:41:21 GMT
1.2b4 and b7 probably can produce garbage for OPTIONS, but b9 should be
ok... oh wait, b9-dev.  I haven't checked when the r->allowed == 0 test
went in, but it was somewhere around there.  This was a bug I noticed
while testing rfc2068-compliance and forcing TRACE when no options were
otherwise set was Roy's suggestion.  (Because Allow: requires at least one
option to be present.)

The 2+ is just to avoid the leading ", ". 

Dean

On 12 May 1997, James H. Cloos, Jr. wrote:

> I tried this on three of our servers, 1.2b4-dev (19961228140010
> snapshot), 1.2b7 and 1.2b9-dev (19970422130013 snapshot).  All give
> what looks like the same corruption as Marc.
> 
> The value of the Allow header varies each time, but it looks like a
> pointer pointing to a random location in vm.
> 
> Interesting point:  commenting out the 
> 
> 	<Location /server-status>
> 	SetHandler server-status
> 	</Location>
> 
> makes it work.  allow is set to `GET, HEAD, OPTIONS, TRACE' and the
> reply is a 405 Method Not Allowed, rather than the 501 one get's
> otherwise.
> 
> I note that make_allow() in http_protocol.c returns "TRACE" if
> r->allowed=0 and returns 2+pstrcat(r->pool, ... NULL) otherwise.
> 
> Why return 2+ the output of pstrcat() vs just "TRACE"?
> 
> -JimC
> -- 
> James H. Cloos, Jr.	<URL:http://www.jhcloos.com/>
> Senior Engineer		cloos@jhcloos.com, cloos@io.com
> IOCOM Ltd.		LPF,Usenix,SAGE,ISOC,ACLU
> 


Mime
View raw message