Hi, I think I found the problem, try this patch, let me know if it
solves your problem :
*** proxy_http.c Fri Jun 14 19:14:57 2002
--- proxy_http_new.c Mon Aug 19 13:52:28 2002
***************
*** 734,744 ****
"server: ", buffer, NULL));
}
backasswards = 0;
buffer[12] = '\0';
r->status = atoi(&buffer[9]);
! buffer[12] = ' ';
r->status_line = apr_pstrdup(p, &buffer[9]);
/* read the headers. */
--- 734,749 ----
"server: ", buffer, NULL));
}
backasswards = 0;
+ //Store byte 12 in buffer[0] for safekeeping
+ buffer[0] = buffer[12];
buffer[12] = '\0';
r->status = atoi(&buffer[9]);
! //Put back position 12 and reset buffer[0] to 'H'
! buffer[12] = buffer[0];
! buffer[0] = 'H';
!
r->status_line = apr_pstrdup(p, &buffer[9]);
/* read the headers. */
What does it do ? When a HTTP header is received without a description,
byte 12 will be \0. In this case, the old code would overwrite the \0
with a space, adding garbage at the end. This will probably be
interpreted by the outputwriter as a newline, thus the creation of the
problem. Is this correct ? Can anybody check this ?
Thanks !
Peter.
Peter Van Biesen wrote:
>
> Hi,
>
> I've investigated further and I see strange things happening :
>
> Direct conntection :
>
> # wget -S --proxy=off http://www.argenta.be
> --11:29:28-- http://www.argenta.be/
> => `index.html.2'
> Resolving www.argenta.be... done.
> Connecting to www.argenta.be[62.233.1.156]:80... connected.
> HTTP request sent, awaiting response...
> 1 HTTP/1.1 200
> 2 Date: Mon, 19 Aug 2002 09:27:03 GMT
> 3 Server: web server
> 4 Set-Cookie: ASPSESSIONIDQQGGGQLW=GIHBKICAKHGMILKNGEHDOBLI; path=/
> 5 cache-control: private
> 6 Connection: close
> 7 Content-Type: text/html
>
> Through the proxy :
>
> wget -S http://www.argenta.be
> --11:28:22-- http://www.argenta.be/
> => `index.html.1'
> Resolving vlafo3... done.
> Connecting to vlafo3[193.190.145.66]:80... connected.
> Proxy request sent, awaiting response...
> 1 HTTP/1.1 200
> 2
> 3 Date: Mon, 19 Aug 2002 09:28:22 GMT
> 4 Server: web server
> 5 Set-Cookie: ASPSESSIONIDQQGGGQLW=PHHBKICAHBJJACKGMCPAJPAC; path=/
> 6 cache-control: private
> 7 Content-Type: text/html; charset=ISO-8859-1
> 8 Via: 1.0 www.argenta.be
> 9 Content-Length: 758
> 10 Connection: close
>
> Notice the extra empty line when going through the proxy. Something I
> also notice that is different is the HTTP line : on other sites, the
> line includes " OK", but here it is not present. I know some regexp's
> will fail on this line ...
>
> I'll check the code if I have the time !
>
> Anyway, I haven't tested the 302 response, what http headerline must I
> send to the server to get a 302 response ?
>
> Cheers,
>
> Peter.
> Brett Hutley wrote:
> >
> > J.D. Silvester wrote:
> > *snip*
> >
> > >I just looked at the source for that web page and this is what I got:
> > >
> > >Date: Fri, 16 Aug 2002 14:03:26 GMT
> > >Server: RealPage 2700
> > >Location: http://server1.someserver.com/webpage.html
> > >Content-Type: text/html
> > >X-Cache: MISS from xxx.xxx.xxx.xxx
> > >Transfer-Encoding: chunked
> > >
> > >9d
> > ><HTML><HEAD><TITLE></TITLE></HEAD><BODY>
> > ><H2></H2>
> > > <A HREF="http://server1.someserver.com/webpage.html";> </A>
> > ><P></BODY></HTML>
> > >
> > >0
> > >
> > >
> > >That is exactly how it appears in the Netscape source viewer. I
> > >especially like the "space link". So, I'm guessing that the extra junk at
> > >the bottom after the headers is what is causing the problem?
> > >
> > >
> > >
> > What you need to do is have a look at the HTTP headers that the server
> > that is doing the redirect sends BEFORE they hit your proxy server. An
> > easy way to do this is to use 'wget -S' (I wish I'd known this the other
> > day - I was using tcpdump to sniff the packets...). For example, when I
> > fire it at my host:
> >
> > wget -S host.example.com
> >
> > I get back:
> >
> > HTTP request sent, awaiting response...
> > 1 HTTP/1.0 200 OK
> > 2 Server: Zope/(Zope 2.5.1b1 (OpenBSD package zope-2.5.1b1)
> > 3 , python 2.1.2, openbsd3) ZServer/1.1b1
> > 4 Date: Fri, 16 Aug 2002 22:52:44 GMT
> > 5 Connection: Keep-Alive
> > 6 Content-Type: text/html
> > 7 Etag:
> > 8 Content-Length: 289
> >
> > ... and you can immediately see the bad line number 3, without the
> > all-important colon.
> >
> > Cheers, Brett
