https://bz.apache.org/bugzilla/show_bug.cgi?id=65631
--- Comment #1 from Yann Ylavic <[email protected]> --- Hi Pavel, > I was getting lots of code 500 for CONNECT method in my proxy access log and > very long lasting requests in server-status lately. The logs show no timings so the "very long lasting requests" point is difficult to diagnose here. > I tried to dig a little bit so you can check end of debug/trace output of > one such request (ip addresses and server name were obfuscated, sorry): [snip] > > The point is that the proxy got 'End of file found' but tried to continue. Yes, the tunnel (and TCP) handles half-closing (i.e. one way closing then the other) because some tunneled protocols work like this: once one end has nothing more to write it will shut down its connection "for write" but will still read any data sent by the peer until it in turn shuts down "for write" itself. Thus it's only when the connection is shut down in both ways that the tunneling ends. > > I'm not sure if it's not obsolete, but RFC2817 says: > > 5.3 Establishing a Tunnel with CONNECT > ... > If at any point either one of the peers gets disconnected, any > outstanding data that came from that peer will be passed to the other > one, and after that also the other connection will be terminated by > the proxy. If there is outstanding data to that peer undelivered, > that data will be discarded. Unfortunately this does not define what "disconnected" means, half-closed connections are still "connected" for instance in some way, but connections reset (implying both ways) are not. So mod_proxy will stop the tunneling (per above) if a read returns an error, but EOF (End Of File) is not considered an error. > > Therefore I tried to apply simple and ugly hack and the strangest thing has > happend. It seems to change those pesky 500 to 200 and I don't see any > hanging connections anymore. Where does the tunneling hangs actually? Timings? What should happen is that when the proxy sends a shutdown/FIN on the opposite side of the tunnel where it received the shutdown/FIN itself, and when the peer receiving the FIN is not willing to send more data (which is immediately the case of any application that does not handle half-closing), the peer should in turn close/FIN the connection which the proxy detects and then forwards on the other side, etc until everything is shut down both ways. Some applications don't close/FIN the connection when they receive a FIN but rather reset/RST it, which seems to be your case. Still the tunneling should end as soon as this RST is received by the proxy, so it does not explain the "hang". > Can somebody check attached patch and write me what he or she thinks of it > please? It breaks half-closing so before anything it would be useful to understand why it hangs in the first place.. As for the 500 in the access, it's possibly something the proxy can do about if it happens during half-closing.. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
