Re: Content-Length was Test Indicator Issue

[Prasad Yendluri <pyendluri@webmethods.com>]

I watched this issue discussed passionately several times over. There are
certainly justifications for both keeping and removing it. Hence I think it
would be a safer bet to not require it to be present but if present require it
to compliant with an HTTP RFC (2616). I am reproducing the text from 2616 below
for reference:

    "If a Content-Length header field (section 14.13) is present, its
     decimal value in OCTETs represents both the entity-length and the
     transfer-length. The Content-Length header field MUST NOT be sent
     if these two lengths are different (i.e., if a Transfer-Encoding
     header field is present). If a message is received with both a
     Transfer-Encoding header field and a Content-Length header field,
     the latter MUST be ignored."

Regards, Prasad

Nicholas Kassem wrote:

> >
> >Issue 2: Content-Length.
> >It was agreed unanimously that it be removed from all but the HTTP
> >binding (transport-level header).
> >---
> >    I disagree with this strongly. This forces implementors to use a
> >regular expression or similar matching pattern to grab out each segment
> >of the entire message. This makes for slow, clunky implementations that
> >may or may not agree with each other. A content-length header is
> >invaluable to message parsing for simplicity and speed. It also gives a
> >great starting point for message digests, signing and encryption.
> >Security is an upcoming issue in TRP if I am not mistaken. I believe the
> >issue of parsing payloads will come back to bite us if Content-Length is
> >not communicated explicitly from sender to receiver.
> >
> >    That said, can someone explain why this was brought out? It doesn't
> >seem to do any good. I think that what is really needed here is a
> >clearer description of Content-Length calculation in the specification;
> >including at least one sample of a complete wire dump of an actual
> >transmission. The ones I have seen passed around from the Tokyo
> >demonstration were, in some places, contradictory to each other, or to
> >known specifications.
> >
> >    It seems as though the design was changed to conform to the proof,
> >rather than the other way around. Can someone from TRP shed light on this?
>
> I disagree with removing the Content-Length too. I don't think we have (as
> yet) fully exercised the potential of compound messages (multiple payloads)
> and hence may be prematurely discounting the value of having an early
> "hint" for the size of a given payload element. This hint may be useful for
> triggering different optimization strategies and algorithms depending on
> payload type/size. IMHO, I believe most of the implementation problems
> encountered to-date could be handled via word-smithing the spec.
>
> Nick

--
Principal Architect, ATG; webMethods Inc.,
432 Lakeside Drive, Sunnyvale, CA 94088-3793, USA
Tel: (408) 692-5226 mailto: pyendluri@webmethods.com