RE: Large content size value

William A. Rowe, Jr. said:
> Scott Lawrence wrote:
> >
> > Yes we have.   For a large body in a request, the server can return an
> > error; the client is required to abort sending the body if an error is
> > received.  For a large body in a response, it's not lovely, but it's
> > well understood - the client just closes the connection.  Since there is
> > no 3-way handshake, that's the best that can be done.
>
> +1, this is well understood and reasonably well documented.

(Send me links?)

> There is no need, and significant arguments against defining a range for
> DIGIT*1 as anything less than infinity, and it is up to the implementor to
> decide what it can parse, what it cannot parse yet still work around, or
> what it simply cannot work around.  Disconnecting, in the third case, is
> the only remaining alternative...

Yeah, but the second case can be pretty ugly, given what the spec allows.

<snip>

> So (s. 8.1.4 Practical Considerations) "A client, server, or proxy MAY
> close the transport connection at any time" is the final word.

That's always an *option*, yes (but it's not the *only* option).

> Unless I'm mistaken, if the client is unwilling to handle the server's
> response, the client MUST (gracefully? abruptly?) close the transport
> connection.

I don't see any MUST. As you pointed out, there are three basic scenarios:
parse it right, parse it fuzzy, and fail. Parse it right is out, so that
leaves parse it fuzzy and fail. The spec shows no preference for one over
the other, BUT "parse it fuzzy" can cause some serious problems (see my
argument earlier in this thread). I totally agree that fail is the right
choice.

<snip>

> There is no need to proceed with this discussion.  There's an opportunity
> to expand upon 8.1.4 offering that the client may disconnect with example
> reasons; or an opportunity to expand upon 8.2 for the converse of 8.2.4.
> The participants here, and the host of implementors to date, seem to have
> no problem understanding this from the existing spec.

I think the opportunity should be taken; "it's never been a problem before"
doesn't strike me as very compelling. Cost/benefit wise, I'd say it's a win,
but I'm not an editor.

<snip>

> Can we please move on?

Sure. I have my answer, there are no new points here, and there's enough
discussion for interested parties to draw an informed conclusion.

Received on Friday, 5 January 2007 23:51:19 UTC