Article delegate-en/1730 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A1728@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Antwort: Re: [DeleGate-En] Antwort: Re: [DeleGate-En] broken post-response with http/1.0 keep-alive
02 Jul 2002 13:47:34 GMT feedback@delegate.org (Yutaka Sato)


Hi Marc,

On 07/02/02(21:15) you "Marc Pohl" <pwudabdyi-p5lznxkemzxr.ml@ml.delegate.org> wrote
in <_A1728@delegate-en.ML_>
 |>But the quick fix is not desirable because it will split a response
 |>data into more packets.
 |>From your experiment, I think the problem between IE and DeleGate could
 |>be caused when the header and body is sent split into different IP
 |>packets.
 |Ethereal shows, that in our case the header and the body of the
 |post-request where definitly split in separate packets.

And after you applied my patch, the post-response message became
not split but sent in a packet.  Also applying FTOCL to response
message causes the same effect.  Can I understand so?

 |>Investigating the http.c, I found that DeleGate split header and body,
 |>by flushing outgoing FILE stream, when the body is a short one of text
 |>type.  This unintended behavior seems to be introduced at DeleGate/3.0.0
 |>on Jan 1996.  I'll fix it as enclosed patch does, and expect it solves
 |>your case.
 |
 |I have tried this patch and it looks very good (yes, the former patch was
 |removed ;-)). Because of this i have now deployed the new version to the
 |production server.

Unnecessarily splitting header/body, especially when it is done for
a small message, will make the transmission efficiency worse.  Thus
I think this patch is desirable even if it does not solve your case :-)
Anyway I thank you for your detailed observations about the problem.

Here I can write another scenario which can explain the situation:
MSIE has some internal flag which indicates that "current response
message has no body part". The flag become ON after 304 response,
and not reset in the next response when the connection is kept
by Proxy-Connection:Keep-Alive.  In this status, if a response message
arrived without "Content-Length", and without body part right after
the header part (in a single packet or in a certain short timeout),
IE judges that the message has no body part, i.e. empty document.
Of course because I can't read the IE source, it is just one of
possible scenarios.  (But if adding Content-Length header solves
the problem, it becomes more provable)
 
Cheers,
Yutaka
--
  @ @ Yutaka Sato <y.sato@delegate.org> http://www.delegate.org/y.sato/
 ( - ) National Institute of Advanced Industrial Science and Technology (AIST)
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan

With Proxy-Connection:Keep-Alive of HTTP/1.0,
With implicit Keep-Alive of HTTP/1.1
With filters, a response message will be sent as a whole without

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V