OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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..

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.

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.

Hope this is useful,

Warren Buckley

> -----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
> >
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC