Re: Conent length with MIME header

[dick@8760.com]

Comments inline marked with <db> </db>

----- Original Message -----
From: Warren Buckley <Warren.Buckley@XIAM.com>
To: <dick@8760.com>; Burdett, David <david.burdett@commerceone.com>; ebXML
Transport (E-mail) <ebxml-transport@lists.ebxml.org>
Sent: Tuesday, November 07, 2000 4:58 AM
Subject: RE: Conent length with MIME header


> Folks,
>
> Dick has correctly pointed out the requirements of HTTP/1.0 and HTTP/1.1.
>
> I think we should consider the following.
>
> There are 3 instances of Content-Length in the spec.
>
> 1. In the Message Envelope (7.2.2)
> 2. In the Header Container (7.3.2)
> 3. In the Payload Container (7.4.2)
>
> It is my view that the requirement of ANY of these will cause an issue with
> streaming content through a network for the reasons I previously gave. ie.
> recalculation or sizes, requirement for extra intermediate capacity, etc..
>

<db>
I agree, streaming content and Content-Length don't fit together. As an
editorial note: I don't recall seeing  a use case for streaming content in the
delivery matrix. If we are planning to support streaming content we will need a
use case.  Is this a phase 2 or 3 item?
</db>


> First, 2 and 3 have no relation to HTTP compatability and are not standard
> MIME headers. I don't think Dick was referring to these Content-Lengths and
> assume the general concensus is to remove them.
>

<db>
It's true that Content-Length is not a MIME standard header, but as was pointed
out in the HTTP spec it is needed in some cases. With regard to items 2 and 3,
the content-length header was included primarily for efficiency purposes.
Consider the case where an intermediary server is processing a large file, it's
much less work for a server to extract a precise number of octets from a payload
as opposed to performing boundary string comparisons over the content in search
of "the end". I believe ebXML will work without the content-length on header and
payload body parts, but it will result in a less efficient (IMO) operation. This
may not be a big deal for point-to-point cases, but a large intermediary, like
Commerce One or Ariba, is more likely to experience the difference in overhead
when they're repackaging.

I know memory is cheap and hopefully Moore's Law will hold for at least another
30 years so perhaps I shouldn't be concerned ( this comes from programming
PDP-11's when one only had a 32k memory space and overlays were a fact of life).
</db>


> Finally to deal with 1.
>
> HTTP/1.1 has introduced the concept of chunked transfer encoding where
> instead of having to know the total-length upfront you only need to know the
> size of the chunk you're currently sending. As Dick highlighted this should
> only be used with HTTP/1.1 servers and should be sent to HTTP/1.0. Shouldn't
> the choice to use 1.0 or 1.1  be made at the HTTP level not the ebXML
> Message Envelope level?
>
> Surely, the Message Envelope should be defined solely using MIME and not
> imposing restrictions where they are not necessary.
>
> So if you produce a Message Envelope and are sending it using HTTP/1.0 then
> as part of the transportation requirements Content-Length must be added to
> the HTTP headers. If you're using SMTP or HTTP/1.1 or some other transport
> protocol that doesn't requirement upfront sizing then you don't need it.
>
> I agree with Dick's suggestion that Content-Length (1) should be part of
> binding the message envelope to HTTP/1.0 but not HTTP/1.1.
>
> Futher, I propose that ALL Content-Length headers be removed from the spec.
>

<db>
If the consensus is to remove Content-Length from the "definitive" parts of the
ebXML message envelope then we will have to specify details for its use under
the HTTP section of TRANSPORT BINDINGS (which I believe is still TBD).

The Content-Length gives more control to system administrators by allowing them
to block large transfers BEFORE consuming system resources. It also provides
efficiencies for intermediaries that deal with unpacking/repacking payloads in
(hopefully) high volumes.

I've provided the logic behind why Content-Length was included in ebXML's
packaging. I wouldn't oppose removal if the group consensus was to do so.
Hopefully, I've provided a reasonable understanding of the "trade-off" in making
this decision.
</db>

Dick Brooks
http://www.8760.com/

>
> > -----Original Message-----
> > From: Dick Brooks [mailto:dick@8760.com]
> > Sent: Monday, November 06, 2000 10:47 PM
> > To: Burdett, David; ebXML Transport (E-mail)
> > Subject: RE: Conent length with MIME header
> >
> >
> > David,
> >
> > There are a couple of factors to consider wrt Content-Length:
> > 0
> > The HTTP 1.1 spec (rfc 2616) states:
> >
> > In section 4.4:
> >
> >   "For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
> >    containing a message-body MUST include a valid
> > Content-Length header
> >    field unless the server is known to be HTTP/1.1 compliant. If a
> >    request contains a message-body and a Content-Length is not given,
> >    the server SHOULD respond with 400 (bad request) if it cannot
> >    determine the length of the message, or with 411 (length
> > required) if
> >    it wishes to insist on receiving a valid Content-Length."
> >
> > Then again in section 14.13:
> >
> >    "In HTTP, it SHOULD be sent whenever the message's length can be
> >     determined prior to being transferred, unless this is prohibited
> >     by the rules in section 4.4."
> >
> >
> > IF ebXML mandates that only HTTP 1.1 servers are supported
> > then we could
> > eliminate the Content-Length, BUT...
> >
> > Another use for the Content-Length header is to allow an
> > E-Commerce site
> > administrator the ability to "block" large file transfers. Without a
> > content-length header you cannot determine the size of a
> > message until its
> > been received in its entirety.  Content-Length also provides
> > an elegant way
> > to check if there is enough available disk space before
> > attempting to save
> > the contents on disk.
> >
> > In summary, the content-length gives system implementers a way to
> > efficiently stop processing data that exceeds a size threshold BEFORE
> > consuming system resources, including all available disk
> > space (which could
> > render an E-Commerce server unusable).  I do see your point
> > about it being
> > non-MIME-standard, perhaps it would make more sense to remove
> > it from the
> > "message envelope" specification but include it in the HTTP transport
> > binding.
> >
> > Your thoughts on this?
> >
> > Wish I was in Tokyo to partake in all the fun - looking
> > forward to seeing
> > you in Vancouver.
> >
> > Dick Brooks
> > Group 8760
> > 110 12th Street North
> > Birmingham, AL 35203
> > dick@8760.com
> > 205-250-8053
> > Fax: 205-250-8057
> > http://www.8760.com/
> >
> > InsideAgent - Empowering e-commerce solutions
> >
> > > -----Original Message-----
> > > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > > Sent: Monday, November 06, 2000 3:54 PM
> > > To: Dick Brooks (E-mail); ebXML Transport (E-mail)
> > > Subject: Conent length with MIME header
> > >
> > >
> > > Dick
> > >
> > > In the TRP meeting today there was a debate over content-length
> > > in the MIME
> > > header. The general conclusion was that we did not want to
> > > include it as it
> > > was a non-standard MIME header and various members of the POC
> > > group thought
> > > that we would be better of without it.
> > >
> > > We really need your feedback on why keeping it is a good idea. We
> > > also need
> > > to finalize this and would like to do this during the conference
> > > call to be
> > > held on 16th November.
> > >
> > > David
> > >
> > > Product Management, CommerceOne
> > > 4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
> > > Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> > > mailto:david.burdett@commerceone.com; Web:
> > http://www.commerceone.com
> > >
> >