http: shutdown output of client socket, server immediately closes connection
HK
seems to translate into the system call
shutdown(socket, SHUT_WR)
to signal EOF to an HTTP server. It seems the
server takes this message so serious that it
does not send any pending response
data, but instead closes the connection
immediately.
Does anyone here know enough about HTTP to
confirm that this is correct and to be
expected behaviour for an HTTP server?
Otherwise I would have to seek for a
different reason why the server does
not send all the data.
Thanks,
Harald.
Michael Wojcik
In article <1122996120.3...@g47g2000cwa.googlegroups.com>, "HK" <pifp...@gmx.de> writes:
> I am using socket.shutdownOutput() in Java which
> seems to translate into the system call
>
> shutdown(socket, SHUT_WR)
>
> to signal EOF to an HTTP server.
Then you're not complying with the HTTP specification, which gives
a user agent ("client") three ways to indicate the end of a request:
- the header separator, for requests with no content-body
- the content-length attribute in the header
- the "chunked" transfer-encoding
Half-closing the connection isn't an option in HTTP, unfortunately.
> It seems the
> server takes this message so serious that it
> does not send any pending response
> data, but instead closes the connection
> immediately.
That's valid, since your client is non-conforming. Arguably it'd be
better if the server processed the request (if it's valid when the
client does its half-close) or rejected it (if it's not), but that's
a quality-of-implementation issue, not a conformance one.
> Does anyone here know enough about HTTP to
> confirm that this is correct and to be
> expected behaviour for an HTTP server?
It's not covered by the specification (RFC 2616, for HTTP/1.1), which
does not acknowledge the possibility of a half-close. We discussed
this strange omission in the HTTP specification here a couple of weeks
ago.
--
Michael Wojcik michael...@microfocus.com
"We are facing a dire shortage of clowns," said Erickson, also known as
Jingles.
Villy Kruse
Michael Wojcik <mwo...@newsguy.com> wrote:
>
> Then you're not complying with the HTTP specification, which gives
> a user agent ("client") three ways to indicate the end of a request:
>
> - the header separator, for requests with no content-body
> - the content-length attribute in the header
> - the "chunked" transfer-encoding
>
> Half-closing the connection isn't an option in HTTP, unfortunately.
>
The server can't tell the difference between half-close and close.
Both result in a FIN sent to the server. The normal result of a client
abort (clicking on stop) is to close the socket (FIN sent to server)
and the server will react by discarding the (rest) of the request.
Villy
HK
> In article <1122996120.3...@g47g2000cwa.googlegroups.com>, "HK" <pifp...@gmx.de> writes:
> > I am using socket.shutdownOutput() in Java which
> > seems to translate into the system call
> >
> > shutdown(socket, SHUT_WR)
> >
> > to signal EOF to an HTTP server.
>
> Then you're not complying with the HTTP specification, which gives
> a user agent ("client") three ways to indicate the end of a request:
>
> - the header separator, for requests with no content-body
> - the content-length attribute in the header
> - the "chunked" transfer-encoding
>
> Half-closing the connection isn't an option in HTTP, unfortunately.
That was exactly the information I was looking for. You saved
me reading, interpreting and understanding the whole HTTP spec.
Thanks a lot,
Harald.
HK
Ok that make sense. Not an expert in TCP/IP I did not know
this detail. For a high load web server sending data out
not knowing if anyone is listening would certainly
be a waste.
Thanks,
Harald.
Michael Wojcik
In article <slrndf0r6...@station02.ohout.pharmapartners.nl>, Villy Kruse <v...@station02.ohout.pharmapartners.nl> writes:
> On 2 Aug 2005 17:34:21 GMT,
> Michael Wojcik <mwo...@newsguy.com> wrote:
>
> > Then you're not complying with the HTTP specification, which gives
> > a user agent ("client") three ways to indicate the end of a request:
> >
> > - the header separator, for requests with no content-body
> > - the content-length attribute in the header
> > - the "chunked" transfer-encoding
> >
> > Half-closing the connection isn't an option in HTTP, unfortunately.
>
> The server can't tell the difference between half-close and close.
> Both result in a FIN sent to the server.
Sure it can, by trying to send the response. (It can try to send just
the response-line first, to avoid further processing if the client has
done a full close.)
> The normal result of a client
> abort (clicking on stop) is to close the socket (FIN sent to server)
> and the server will react by discarding the (rest) of the request.
True, but irrelevant. The OP's client is non-conforming because the
spec doesn't support half-close. I still say that RFC 2616 should
acknowledge the possibility of half-close; as it's written, it's
simply wrong (for HTTP over TCP), as we discussed a few weeks back.
--
Michael Wojcik michael...@microfocus.com
Against all odds, over a noisy telephone line, tapped by the tax authorities
and the secret police, Alice will happily attempt, with someone she doesn't
trust, whom she can't hear clearly, and who is probably someone else, to
fiddle her tax return and to organise a coup d'etat, while at the same time
minimising the cost of the phone call. -- John Gordon
Rick Jones
>> Both result in a FIN sent to the server.
> Sure it can, by trying to send the response. (It can try to send
> just the response-line first, to avoid further processing if the
> client has done a full close.)
It can, but should it?
It would then trigger a RST which would then "assasinate" the
TIME_WAIT state which is considered a Bad Thing (tm).
rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Michael Wojcik
In article <w3sIe.9858$9a6....@news.cpqcorp.net>, Rick Jones <rick....@hp.com> writes:
> >> The server can't tell the difference between half-close and close.
> >> Both result in a FIN sent to the server.
>
> > Sure it can, by trying to send the response. (It can try to send
> > just the response-line first, to avoid further processing if the
> > client has done a full close.)
>
> It can, but should it?
It's debatable. My point, though, is not whether it would be good
for RFC 2616 to allow this - it'd be good if RFC 2616 acknowledged
the possibility, rather than making an erroneous claim.
> It would then trigger a RST
Yes, if the client had done a full close and not a half-close.
> which would then "assasinate" the TIME_WAIT state
Eh? The server is in ESTABLISHED state and receives a FIN; it goes
into CLOSE_WAIT. There's no transition from there into TIME_WAIT -
the TIME_WAIT is on the client's side, if the client performed the
active close, as it did in this case. So there's no TIME_WAIT to
be assassinated on the server side.
The client, meanwhile, has transitioned to FIN_WAIT_1. Stevens, at
least, doesn't show any way to avoid TIME_WAIT once you're in
FIN_WAIT_1 - all transitions get you to TIME_WAIT eventually.
The only state in which RFC 1337 shows TWA occurring is in TIME_WAIT,
and that's not where the client is when it sends its RST. Further,
RFC 1337 warns that TWA will happen when the active-closing side
*receives* an RST, not when it sends one.
Perhaps typical implementations will transition to CLOSED from
FIN_WAIT_1 on receipt of data. I haven't tested it. It's not the
classic TWA case, though.
(I'll be on vacation next week, so I probably won't see any replies
for a while.)
--
Michael Wojcik michael...@microfocus.com
Reversible CA's are -automorphisms- on shift spaces. It is a notorious
fact in symbolic dynamics that describing such things on a shift of finite
type are -fiendishly- difficult. -- Chris Hillman