On Monday 18 April 2011, Torsten Förtsch wrote: > On Monday, April 18, 2011 10:36:13 Joe Orton wrote: > > If you change the CGI script to send a 100 rather than 102, does > > it work? LWP should treat all 1xx as interim responses so I'd > > say it is an LWP bug. > > It is certainly triggered by the LWP version upgrade. I also agree > that it's a bug in LWP. But my question was also what do we test > here? If the purpose of the test is to see if the 102 response is > passed through (as suggested by the comment) then I'd think the > test is wrong too.
IMHO the purpose is to test if the real (200) response is passed through. For me, a tcpdump gives: ================ GET /reverse/modules/cgi/nph-102.pl HTTP/1.0 Host: localhost:8541 User-Agent: libwww-perl/6.01 HTTP/1.1 200 OK Date: Mon, 18 Apr 2011 18:33:25 GMT Server: Apache/2.3.12-dev (Unix) mod_ssl/2.3.12-dev OpenSSL/1.0.0d DAV/2 Content-Type: text/plain Connection: close this is nph-stdout ================ Note that the test requests HTTP/1.0. RFC 2616 says "servers MUST NOT send a 1xx response to an HTTP/1.0 client", so mod_proxy is correct not to forward the 102 response to the client. Maybe the newer LWP sends an HTTP/1.1 request? Can you confirm this with tcpdump? Which version of LWP do you use? For HTTP/1.1 clients, RFC 2616 says " A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent." I am not sure what is meant with the last sentence, but the first sentence seems to indicate that LWP returning status 102 is a bug. Cheers, Stefan
