Re: SEQ frames and MIME entity headers

On Thursday, June 6, 2002, at 05:57 AM, Jered Floyd wrote:
> james woodyatt <[email protected]> writes:
>>
>> I think BEEP peers should not send SEQ frames to acknowledge
>> processing of incomplete MIME entity headers.  It would be better, to
>> my mind, if BEEP peers were required to buffer the entire MIME entity
>> header of a message before sending a SEQ frame to acknowledge it.
>
> I also agree that the scenario you describe, in which there are more
> headers than the channel window buffer can hold, is a mess, and adds
> unnecessary complexity.  You suggest that the sending peer could
> increase the channel window size if it wishes to send a long set
> of headers, but BEEP does not currently define a mechanism by which
> a sending peer can request an increase in the channel window size.

That's true, but it doesn't have to.  Applications that depend on that 
feature can define mechanisms in their profiles for doing that.  The 
core profiles don't have any such mechanism, but then-- they don't need 
to send pathologically long entity headers, do they?

>> One of the reasons I bring this up: if I *do* send SEQ frames
>> acknowledging incomplete MIME entity headers, then I have a problem
>> when a malicious peer sends an initial greeting message with a
>> Content-Description field of infinite length.
>
> How is this worse than an XML body of infinite length, say filled
> with whitespace or comments?

All BEEP messages have entity headers.  If an application wants to 
process entity bodies incrementally and still prevent peers from being 
able to send content of unbounded length, its profile can require the 
presence of Content-Length header fields in its message entities.

When an application receives a MSG entity without a required 
Content-Length field, it can immediately produce an ERR entity in 
response.  When receiving any other kind of entity without a required 
Content-Length field, the application can instruct the framework to 
discard the body.

The harder problem is letting applications process entity *headers* 
incrementally, because that forces the application programming interface 
for profiles to support applications having to deal with headers of 
potentially unbounded length.

I think that unnecessarily complicates an already very complicated 
programming interface, and I can't think of any good reasons why 
applications would need to process entity headers incrementally.  Can 
anyone?

>> Plus, it complicates the programming interface for application
>> profiles to have to support pathologically long MIME entity headers,
>
> You applications will often have to support pathologically long
> entities, be they MIME headers or not.

As I said, applications get some control over the size of messages with 
the Content-Length entity header field.  The core profiles can all be 
written in such a way that their messages are completely buffered in the 
channel window and processed atomically.  I'm pretty sure that's one of 
the reasons why RFC 3081 says the initial window size of a channel is 
4096 octets.


--
j h woodyatt <[email protected]>