You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/02/08 16:21:39 UTC

[jira] [Commented] (TS-4092) Decouple HPACK from HTTP/2

    [ https://issues.apache.org/jira/browse/TS-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137062#comment-15137062 ] 

ASF GitHub Bot commented on TS-4092:
------------------------------------

GitHub user maskit opened a pull request:

    https://github.com/apache/trafficserver/pull/460

    TS-4092: Decouple HPACK from HTTP/2

    I tried to decouple HPACK from HTTP2, and it partially succeeded. It's very difficult to completely decouple HPACK unless we use MIMEField in it.
    
    # Changes:
    - Added two functions to HPACK module
       - hpack_decode_header_block
       - hpack_encode_header_block
       
       These functions handle a header block(uint8_t *) and a header list(HTTPHdr *), and convert them from one to another. They simply take care of RFC7541(HPACK). Which means no special treatment for particular headers such as pseudo headers.
       
    - Simplified HPACK related functions in HTTP2 module
       - http2_write_psuedo_headers(removed)
       - http2_write_header_fragment(removed)
       - http2_convert_header_from_1_1_to_2(added)
       - http2_convert_header_from_2_to_1_1(renamed)
       - http2_decode_header_blocks(simplified)
       - http2_encode_header_blocks(added)
       
       The last two functions handle a header block and a header list too, but they take care of RFC7540(HTTP2). They are responsible for handling of sensitive headers, effectiveness (RFC7540 Section 8.1.2.5) and HTTP2 related limitations.
       
    - Added a flag of sensitivity to MIMEField
       The flag is used for determining a representation of a header field when encoding response headers. It will also be used when we support HTTP2 on server side connections because an intermediary needs to remember representation of each header fields to ensure that a never-indexed representation field will not be re-encoded as a indexed representation field (RFC7541 Section 7.1.3). 
    
    # Benefits:
    
    - HPACK module has been simple
       Simple is best.
       
    - HPACK module has been testable
       Our HPACK module has been a pure HPACK implementation. It means we can use external common test cases which other implementations use. It will ensure compatibility.
       https://github.com/http2jp/hpack-test-case
       
    - HPACK module has been (almost) decoupled from HTTP2
       We can use the module not only for HTTP2 but also QUIC (if we support it).
    
    # Issues:
    
    - MIMEField converts header names old fashioned
       Because RFC 7541(HPACK) does not mention about case of characters, we should not change them in HPACK module but MIMEField does against WKSs. So we have to convert the strings to lowercase just before encoding in HPACK module to follow RFC 7540(HTTP2). This blocks complete decoupling.
    
    - Cannot prepend a header field to HTTPHdr
       HTTP2 cares order of header fields. Pseudo header fields must be at the beginning of header fields. To convert HTTP1.1 header to HTTP2 header, we need to prepend pseudo header fields to a existing HTTPHdr. However, the only way to achieve this is creating new HTTPHdr for now. It does cost. The same thing will happen when we support HTTP2 on server side connection. This would affect performance.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/maskit/trafficserver ts4092

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/trafficserver/pull/460.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #460
    
----
commit 3f5ac05a50443ce77201746061f43f5804eff4ec
Author: Masakazu Kitajo <ma...@apache.org>
Date:   2016-02-08T14:52:59Z

    TS-4092: Decouple HPACK from HTTP/2

----


> Decouple HPACK from HTTP/2
> --------------------------
>
>                 Key: TS-4092
>                 URL: https://issues.apache.org/jira/browse/TS-4092
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: HTTP/2
>            Reporter: Masakazu Kitajo
>            Assignee: Masakazu Kitajo
>             Fix For: 6.2.0
>
>
> Our HTTP/2 implementation and HPACK implementation are coupled tightly. This is bad. It makes things complicated.
> I tried to write a test runner which uses [hpack-test-case |https://github.com/http2jp/hpack-test-case], however, I had to call functions in HTTP2.cc. Because HPACK.cc has only primitive encoder and decoder, and doesn't handle header blocks. HTTP2.cc covers not only RFC7540 but also some part of RFC7541.
> On the other hand, HPACK.h exports pseudo header names as constants. They should be in HTTP2.h or MIME.h as WKS. We don't need them in HPACK implementation.
> Also, HPACK is used with QUIC (at least in current draft). We should decouple HPACK from HTTP/2 so that we can use the module with QUIC in the future.
> Once we have done this, we can write tests for these improvements more easily.
> TS-4002, TS-4061, TS-4014 and TS-3478



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)