Re: END_SEGMENT? (#397)

>
> Couldn't such protocols include their own delimiters? If a protocol
> running on HTTP/2 is record based, the record delimiters should be
> incorporated into the contents of the DATA frame. Otherwise, this seems
> like an unnecessary layering violation.

I'm interested in WebSocket over HTTP/2 and it uses END_SEGMENT.
The problem of specifying END_SEGMENT in WebSocket over HTTP/2 not in
HTTP/2 is, WebSocket over HTTP/2 can't be used with intermediaries that
merely understand HTTP/2.
I want to avoid such situation if possible.

Thanks,



On Wed, Jun 18, 2014 at 1:23 AM, Daniel Sommermann <dcsommer@fb.com> wrote:

>  Apologies for the (very) late response on this topic. My high level
> question here is if this is strictly needed for interop with 1.1. If not, I
> don't think it warrants the extra complexity and constraints on
> intermediary behavior.
>
> On 04/17/2014 09:25 AM, Jeff Pinner wrote:
>
>
> On Thu, Apr 17, 2014 at 12:52 AM, <K.Morgan@iaea.org> wrote:
>
>>  What is the purpose of END_SEGMENT?
>>
>>
>>
> END_SEGMENTS allows the layering of record-based semantics onto the
> framing layer.
>
>  Consider this use case in HTTP/1.1. An API provides a stream of data
> using HTTP/1.1 chunked encoding. Each chunk contains a single record, and
> the length of this record is indicated by the chunk length. In HTTP/1.1 the
> length of these chunks was unconstrained, but when translating into HTTP/2,
> these chunks must be segmented into multiple data frames to fit within the
> frame size limit.
>
>  If the chunk delineation was meaningful, then END_SEGMENT allows this
> meaning to be preserved.
>
>
> I'm not exactly sure how END_SEGMENT alone can be used to preserve chunk
> semantics. If you are proxying from 2 to chunked 1.1, you would need some
> other flag to know to add transfer-encoding: chunked and then other flags
> to know the chunk lengths. Roberto implied in an earlier message that
> END_SEGMENT is needed to preserve chunk boundaries.
>
>   The flag is also useful for layering other record-based protocols on
> top of HTTP.
>
>
> Couldn't such protocols include their own delimiters? If a protocol
> running on HTTP/2 is record based, the record delimiters should be
> incorporated into the contents of the DATA frame. Otherwise, this seems
> like an unnecessary layering violation.
>
> I'm curious who plans to use this feature and why END_SEGMENT is the only
> way to do it. While not exactly a DOS vulnerability for proxies, placing
> requirements on the framing layer limits how proxies can respond in low
> memory situations (e.g. a memory-constrained proxy might need to forward a
> partially received DATA frame as 2 smaller frames). The "MUST NOT coalesce"
> requirement in particular seems out of place. As with any feature, the
> complexity is also a potential source of bugs.
>
> The other point brought up is that many HTTP APIs will not expose this
> segment information, potentially making it difficult to conform to the
> "intermediaries MUST NOT coalesce" requirement.
>