You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1997/05/10 07:33:06 UTC

incorrect Allow: header?

The below Allow header doesn't look right to me.  I have this
suspicion that this or something similar has come up before, but
can't see it...

	marcs@alive:~$ telnet alive 80
	Trying 127.0.0.1...
	Connected to alive.znep.com.
	Escape character is '^]'.
	POST /server-status/ HTTP/1.1
	Host: alive

	HTTP/1.1 501 Method Not Implemented
	Date: Sat, 10 May 1997 05:31:23 GMT
	Server: Apache/1.2b11-dev
	Allow: TRACE
	Connection: close
	Transfer-Encoding: chunked
	Content-Type: text/html

	9e 
	<HTML><HEAD>
	<TITLE>501 Method Not Implemented</TITLE>
	</HEAD><BODY>
	<H1>Method Not Implemented</H1>
	POST to /server-status/ not supported.<P>
	</BODY></HTML>

	0

Am I crazy?


Re: incorrect Allow: header?

Posted by Dean Gaudet <dg...@arctic.org>.
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
> 


Re: incorrect Allow: header?

Posted by .
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