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

[DeleGate-En] Re: Antwort: Re: [DeleGate-En] Antwort: Re: [DeleGate-En] Antwort: Re: [DeleGate-En] broken post-response with http/1.0 keep-alive
02 Jul 2002 18:58:44 GMT (Yutaka Sato)

Hi Marc,

On 07/03/02(02:47) you "Marc Pohl" <> wrote
in <_A1733@delegate-en.ML_>
 |>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,
 |I don't think that msie is the problem. As i mentioned in my first mail,
 |the body is not even send to the client.

I thought it is because the TCP connection is aborted reset from
the client (IE) side immediately after a header is received, and
before DeleGate flushes the body onto the connection.
Then I thought flushing body right after the header (as the first
patch), or don't flushing after the header (as the next patch)
will pack header and body into a single packet to solve the problem.

 |response from delegate to client:
 |tcp packet 1, 279 raw bytes, tcp-flags (psh, ack), http-header
 |tcp packet 2, 54 raw bytes, tcp-flags (rst, ack), no content
 |I have no great experience with socket-programming, so i don't know what
 |condition could cause a TCP-RST-Flag from the server.

Mee too is not so experienced in TCP.  My patch could be just a
lucky strike :-).  But anyway your detailed observation and description
on the problem will be helpful to understand it in future.

 |Another interesting
 |thing is, that the POST request has one more packet (a trailing \r\n in a
 |separate packet) if the error happens. I have repeated this some times, but
 |the additional packet was always there.

It might be a kind of kindness of IE before it aborts a connection,
to help (proxy) server software which might be blocking waiting
end-of-line ???
If it is sent with RST, and it is sent after IE received header and
before DeleGate sent RST+ACK, then my guess can remain as a possibility:)

  @ @ Yutaka Sato <>
 ( - ) National Institute of Advanced Industrial Science and Technology (AIST)
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan

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