0001078: POST and delayed CRLF

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0001078

[Resin]

minor

always

04-28-06 16:29

06-14-07 11:45

Reporter

ferg

View Status

public

Assigned To

ferg

Priority

normal

Resolution

won't fix

Status

closed

Product Version

Summary

0001078: POST and delayed CRLF

Description

(rep by Jeff-Barca-Hall)

We found out why large form POSTs were occasionally returning errors in
the browser. Resin is not being tolerant of some peculiar browser
behavior that Apache tolerated in our previous configuration.

You may already be aware of the issue: Trailing CRLF on POSTs.

Here's how it's described in the Apache docs
(http://httpd.apache.org/docs/2.0/misc/known_client_problems.html): [^]

   "Trailing CRLF on POSTs
   This is a legacy issue. The CERN webserver required POST data to have
an
   extra CRLF following it. Thus many clients send an extra CRLF that is
   not included in the Content-Length of the request. Apache works
around
   this problem by eating any empty lines which appear before a
request."

Note: I assume the above is referring to requests coming in on http
keep-alive connections; otherwise the CRLF packet (which contains only
those two characters without a request string) would never reach Apache.
However, we are not using http keep-alive.

And, here's Microsoft's acknowledgement that IE can at times mistakenly
think it's talking to a HTTP/1.0 server and send the trailing CRLF when
it's not needed:
http://support.microsoft.com/?scid=kb;en-us;823099&spid=2073&sid=global [^]

Note: Our situation is different than what MS describes in the KB
article; we are not using compressed pages.

What we have observed is that IE does not immediately send the CRLF with
the POST, but appears to waits a bit (approx 250ms in our case). Our
speculation is that IE, not knowing the server type because the response
has not yet been fully received, sends this delayed CRLF after having
not received a response from the POST within some time period, "just in
case" the server is HTTP/1.0 and the absence of that CRLF were the cause
of the delay. Again, pure speculation on our part as to *why* IE is
doing this, but we have no doubt about *what* it is doing.

The reason this causes a problem is that by the time the trailing CRLF
packet arrives at the server, Resin has finished sending out its
response and the server resource associated with the TCP connection has
been (correctly) closed. The server TCP implementation (in our case,
Solaris) rejects the CRLF packet by (correctly) sending a RST back. The
effect is that the browser stops receiving the output Resin sent it and
reports a "Page can not be displayed" error to the user.

We have solved the problem for our site by adding logic to the code
("proxy") we have in front of Resin. Our code now anticipates that a
delayed CRLF packet might arrive after a POST and we safely accept and
ignore it.

Thanks for your earlier responses as we worked through eliminating each
piece of our configuration to get to the bottom of this. Let me know if
you would like any more information from us about this.

Additional Information

Attached Files

Relationships

Notes
(0002049) ferg 06-14-07 11:35	Like Apache, Resin already skips the CRLF before the next HTTP request. So the extra CRLF itself isn't an issue. In this case, however, Resin is acting correctly. It is not feasible for Resin to keep closed connections open for an extra second or so just to work around the IE bug.

(0002051) ferg 06-14-07 11:45	As a workaround, the <keepalive-max> can be increased so Resin never shuts down a keepalive early. That configuration change will prevent this situation from occurring, since Resin will not close the connection until the client does (aside from timeouts.)

Issue History
Date Modified	Username	Field	Change
04-28-06 16:29	ferg	New Issue
04-28-06 18:57	koreth	Issue Monitored: koreth
06-14-07 11:35	ferg	Note Added: 0002049
06-14-07 11:35	ferg	Assigned To	=> ferg
06-14-07 11:35	ferg	Status	new => closed
06-14-07 11:35	ferg	Resolution	open => won't fix
06-14-07 11:35	ferg	Fixed in Version	=> 3.1.1
06-14-07 11:45	ferg	Note Added: 0002051

Mantis 1.0.0rc3[^]

32 total queries executed.
27 unique queries executed.