Comments on draft-ietf-httpbis-http2-04

Michael Sweet <msweet@apple.com> Tue, 09 July 2013 17:13 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1EA21F9E25 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jul 2013 10:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.456
X-Spam-Level:
X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJgC2wRduXLM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jul 2013 10:13:39 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6D57D21F9E1D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 9 Jul 2013 10:13:39 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UwbTD-0008EF-44 for ietf-http-wg-dist@listhub.w3.org; Tue, 09 Jul 2013 17:12:55 +0000
Resent-Date: Tue, 09 Jul 2013 17:12:55 +0000
Resent-Message-Id: <E1UwbTD-0008EF-44@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <msweet@apple.com>) id 1UwbT4-0008DV-0f for ietf-http-wg@listhub.w3.org; Tue, 09 Jul 2013 17:12:46 +0000
Received: from bramley.apple.com ([17.151.62.49] helo=mail-out.apple.com) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_MD5:16) (Exim 4.72) (envelope-from <msweet@apple.com>) id 1UwbT2-0004kL-Kc for ietf-http-wg@w3.org; Tue, 09 Jul 2013 17:12:45 +0000
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_rhWzxKa7d1XrFQxWly47qw)"
Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPO00K2EIGIIQA2@mail-out.apple.com> for ietf-http-wg@w3.org; Tue, 09 Jul 2013 10:12:18 -0700 (PDT)
X-AuditID: 11807157-b7f706d0000006c6-78-51dc4470ba11
Received: from [17.153.23.238] (Unknown_Domain [17.153.23.238]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id D3.81.01734.1744CD15; Tue, 09 Jul 2013 10:12:18 -0700 (PDT)
From: Michael Sweet <msweet@apple.com>
Date: Tue, 09 Jul 2013 13:12:19 -0400
To: "ietf-http-wg@w3.org list" <ietf-http-wg@w3.org>
Message-id: <3072E3B4-63B4-4DFB-AFD8-08EE6407C6FB@apple.com>
X-Mailer: Apple Mail (2.1508)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUiOFP8nW6Ry51AgxOtTBaHW2YxWRz5FuvA 5LH15A82j6Pz9rMGMEVx2aSk5mSWpRbp2yVwZdx9+4qxYHdxxY0dd9kbGKdGdzFycEgImEh8 6s/rYuQEMsUkLtxbz9bFyMUhJNDLJNG4/zcTSIJNQE3i96Q+VhCbWSBBovXrT0aQXhYBFYnb G8JATGEBA4mDMy1BKkSAJt7o+M0CYvMK2EgcmLWKDcLWk1j6bw4jxFZZiZ2/kyYwcs9CMnMW kiqIuLbEsoWvmWcBdTAL6EhMXogmDGF/PH+EaQEj2ypGgaLUnMRKE73EgoKcVL3k/NxNjKCA aigM38H4b5nVIUYBDkYlHt4DCncChVgTy4orcw8xSnAwK4nwJvEBhXhTEiurUovy44tKc1KL DzFKc7AoifNa6t0OFBJITyxJzU5NLUgtgskycXBKNTDWWyX8qA35k2wbE3N8w90FjX+f3O1V PiW/rr0wc7L9S1Flpg/X6pq9XGXNp9gs3bh/TUhR0P5OM+s2kxOHzzrFPpvDbD+rwydd52SA zoEVu+sYJD/dufq5hPPb7jbvikXV71jn1OvfPbmrneXnv+CAzVZH5M4/e6Rz9Oxcnu5ZSYId 7e0BfEFKLMUZiYZazEXFiQC7qrcRJAIAAA==
Received-SPF: pass client-ip=17.151.62.49; envelope-from=msweet@apple.com; helo=mail-out.apple.com
X-W3C-Hub-Spam-Status: No, score=-5.7
X-W3C-Hub-Spam-Report: AWL=-0.366, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.303, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UwbT2-0004kL-Kc b718598543dc56f7b7e0f7e9ce47f63a
X-Original-To: ietf-http-wg@w3.org
Subject: Comments on draft-ietf-httpbis-http2-04
Archived-At: <http://www.w3.org/mid/3072E3B4-63B4-4DFB-AFD8-08EE6407C6FB@apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18653
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

All,

A couple quick comments on draft-ietf-httpbis-http2-04...

In section 8.1.1 Examples I see the following:

   All HTTP Requests that include a body SHOULD include the "content-
   length" header field.  If a server receives a request where the sum
   of the DATA frame payload lengths does not equal the value of the
   "content-length" header field, the server MUST return a 400 (Bad
   Request) error.

I am uncomfortable with this wording primarily because a lot of POST usage consists of streamed content - my particular interest is obviously printing, but any streamed content will necessarily not be able to provide a content-length header field. So instead I would suggest the following two paragraphs instead:

    All HTTP requests that include a body of known length MUST include the "content-length" header field. If a server receives a request where the sum of the DATA frame payload lengths does not equal the value of the "content-length" header field, the server MUST return a 400 (Bad Request) error.

    All HTTP requests that include a body of unknown length MUST NOT include the "content-length" header field. Servers MUST support receiving requests without a "content-length" header field and MUST return a 413 (Request Entity Too Large) error if the body is too large to process.

This clearly defines how clients stream content to servers and defines the error handling required.  And it makes the conformance requirements less squishy...


My other comment is that I don't see any discussion of the Expect header, nor do I see a issue on Github... But this is something that gets used extensively in printing to avoid sending gigabytes of print data to a printer that needs authentication for certain operations...  Perhaps something to add to section 8.1.1, e.g.:


Use of Expect with 100 (Continue) response:

    POST /ipp/print HTTP/1.1            HEADERS
    Host; printer.example.org      ==>    - END_STREAM
    Content-Type: application/ipp         + END_HEADERS
    Transfer-Encoding: chunked              :method = post
    Expect: 100-continue                    :scheme = ipp
                                            :host = printer.example.org
                                            :path = /ipp/print
                                            content-type = application/ipp
                                            expect = 100-continue

    HTTP/1.1 100 Continue          ==>  HEADERS
                                          - END_STREAM
                                          + END_HEADERS
                                            :status = 100

    {binary data from client}      ==>  DATA
                                          + END_STREAM
                                            {binary data}

    HTTP/1.1 200 OK                ==>  HEADERS
    Content-Type: application/ipp         - END_STREAM
    Transfer-Encoding: chunked            + END_HEADERS
                                            :status = 200
    {binary data from server}               content-type = application/ipp

                                        DATA
                                          + END_STREAM
                                            {binary data}

Failed response needing authentication:

    POST /ipp/print HTTP/1.1            HEADERS
    Host; printer.example.org      ==>    - END_STREAM
    Content-Type: application/ipp         + END_HEADERS
    Transfer-Encoding: chunked              :method = post
    Expect: 100-continue                    :scheme = ipp
                                            :host = printer.example.org
                                            :path = /ipp/print
                                            content-type = application/ipp
                                            expect = 100-continue

    HTTP/1.1 401 Unauthorized      ==>  HEADERS
    Content-Type: text/html               - END_STREAM
    Content-Length: 123                   + END_HEADERS
    WWW-Authenticate: Basic ...             :status = 401
                                            www-authenticate = Basic ...
    {HTML error message from server}

Then we'd also need a clarification in section 8.1.3 to allow a single HEADERS response frame with :status = 100.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair