Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 46003 invoked by uid 500); 4 Oct 2000 22:41:06 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 45992 invoked from network); 4 Oct 2000 22:41:05 -0000 Sender: gregames@raleigh.ibm.com Message-ID: <39DBB154.8B087DA3@raleigh.ibm.com> Date: Wed, 04 Oct 2000 22:38:12 +0000 From: Greg Ames X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13-7mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: FW: cvs commit: apache-2.0/src/main http_core.c http_protocol.c http_request.c References: <000701c02e15$77b07da0$92c0b0d0@roweclan.net> <39DB67AE.17B51E5F@raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Greg Ames wrote: > "William A. Rowe, Jr." wrote: > > > Could this problem be related to this effect I'm seeing: > > > > GET / HTTP/1.0 > > > > followed by a single newline returns: > > > > > > > > 501 Method Not Implemented > > > >

Method Not Implemented

> > to /index.html not supported.

> > Invalid method in request

> >


> >
Apache/2.0a7 Server at localhost Port 80
> > > > > > I understand if I've torn my config to shreads lately, but > > this message is hardly parsible by a human being. > > > > Oooops. This isn't the "missing error response body" bug, but part of > this is my bad :-( When I moved the canned error string switch block > into its own function, I dropped the code that picks up r->method for a > 501 error. I will fix that ASAP. After adjusting my contact lenses & breaking out the debugger, that's not the problem at all. > > Beyond that, I don't know why this GET isn't working and why you don't > see response headers. Maybe the request string got clobbered and Apache > is defaulting to HTTP 0.9. When using netcat or any other similar tool which can send in a newline which isn't preceded by a CR, the request line returned by getline() is null. Looks like a bunch of the functionality of ap_bgets() wasn't picked up by the recent input filtering change. I have a patch which gets netcat & such closer to working which I will post. It's still not right, so I won't commit it, but it gets you farther. Greg