==== QUOTE:
> Yes, but the response came while the body was in
> transit already, before it was sent completely, which
> puts the transaction in a very unstable state.  This
> is the reason why the RFC requires the client (i.e.
> it says it "MUST") close the connection if the
> Content-Length header was used.

Can you point me where the rfc say this? Is it the 8.2.2?
====

Yes, section 8.2.2 says:
"[...] If the client sees an error status, it SHOULD
immediately cease transmitting the body. If the body
is being sent using a "chunked" encoding (section
3.6), a zero length chunk and empty trailer MAY be
used to prematurely mark the end of the message. If
the body was preceded by a Content-Length header, the
client MUST close the connection."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2

As I mentioned in my previous message, I believe that
this requirement is because the server responded
early for a reason: it rejected the request, so
sending the rest of the body to satisfy the
Content-Lenght would go against the wishes of the
server.  As we have seen, to compensate for this, the
server "accepts" the body, but silently discards it
(at least that seems to be the behaviour).  This
means that the server is wasting resources in
attending a rejected request.

==== QUOTE:
You said that the client MUST close the connection
when receive the 401. Is the
section above that you are referring?
====

Ah! I'm very sorry, but I think you may have
misunderstood me.  I said that the RFC (section
8.2.2, as quoted above) states that IF an error
response is received early AND a Content-Length
header was used THEN the client MUST close the
connection.


==== QUOTE:
What is still not clear to me is: sending the
response before the client has
finished to send the request break the rfc or not?
====

No. Sending the response before the client has
finished sending the request is allowed by the RFC. 
This is also in secion 8.2.2:

"An HTTP/1.1 (or later) client sending a message-body
SHOULD monitor the network connection for an error
status while it is transmitting the request."

I can't find any place where it explicitly states
that responses can come before the end of the
request.  Nor can I find a place where it explicitly
states that the server must receive the full request
before sending a response.  The RFC seems to imply
that the standard way is for a response to follow the
full request; but parts like section 8.2.2 seem to
imply that this is not a requirement.  For example,
in section 6:

"After receiving and interpreting a request message,
a server responds with an HTTP response message."

It does not expressly say that the server must
respond at the end of the request, just after
interpreting it.  Arguably, an unauthorized request
for a resource that requires authentication can be
clearly "interpreted" and identified as soon as the
headers are received and processed.

In any case, the wording in section 8.2.2 seems to
suggest it strongly.



==== QUOTE:
If this was for security reasons why the server
doesn't close the connection? As
it is actually it receive the rest of the request (at
least if made by IE).
====

Exactly, it's a tricky situation.  On the one hand,
the server does not want to process a lengthy request
which it *knows* is invalid.  On the other hand, it
is bound by the RFC to receive the full length of the
body, as specified in the Content-Length header.  The
RFC therefore puts the responsibility on the client
by saying that it MUST close the connection in such
cases.

If the client closes the connection, then everything
falls into place:  The client can re-connect and
re-send the request with the appropriate
authentication header (if it has the credentials),
and the server can easily ignore the previous
unauthorized request.  All is well except for NTLM,
which requires the connection to be kept open.

By the way, when I said "security reasons", I meant
to prevent a Denial-Of-Service attack.


==== QUOTE:
> If a Content-Length header was provided, the client
> MUST close the connection.

IE don't do so, but works (ok, it is a M$ product,
following the rules is not
very frequent ;).
====

Are we confident that IE received the response early?
 Perhaps it defers acknowledging responses until
after the body is fully sent.  (The RFC does say that
the client "SHOULD" monitor for early error
responses, it does not say they "MUST".)

Also, as we have seen, the RFC seems a little vague
in this regard, so it is entirely possible that this
particular exceptional case was not considered too
much.  RFC 2616 does not discuss authentication at
all, it was deferred to RFC 2617; but that RFC does
not consider transport problems (since that is part
of RFC 2616).

Furthermore, RFC 2616 has this to say about Denial Of
Service Attacks:

"They exist. They are hard to defend against.
Research continues. Beware. "

Which does not help much.  In any case, if it works
for IE, it can work for us.  Perhaps Firefox works
the same way.  We could ignore the RFC (like them)
and send the full body.  This will certainly work. 
But keep in mind that it is a waste of time and
resources for all parties involved to send a
potentially large request in its entirety twice
(first unauthorized, then authorized).

Perhaps for NTLM connections the best course of
action would be to send a HEAD request to retrieve
the challenge-response token, instead of having to
send the request multiple times.

==== QUOTE:
I'm unable to find where the rfc describe clearly a
situation like this, but I
read only the sections that I think are related and
probably I missed the right one.
====

The RFC suggests clearly, while not stating
explicitly, that servers may send a response before
the entire body of the request is received (i.e.
"[a]fter receiving and interpreting a request
message", whenever that is).  I know it's a bit of a
stretch, but otherwise section 8.2.2 would be invalid
or irrelevant.

    Cheers!
    -dZ.

-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to