source: wg_materials/ietf95/ietf-95-httpbis-header-field-parsing.xhtml @ 2755

Last change on this file since 2755 was 2755, checked in by julian.reschke@…, 4 years ago

cleanup

  • Property svn:executable set to *
File size: 6.3 KB
Line 
1<!DOCTYPE html
2  PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3<html xmlns="http://www.w3.org/1999/xhtml">
4  <head>
5    <title>IETF 95 - Thoughts on HTTP Header Field Parsing</title>
6    <style type="text/css">
7body {
8  color: black;
9  font-family: cambria, helvetica, arial, sans-serif;
10  font-size: 18pt;
11}
12h1 {
13  font-size: 36pt;
14}
15pre {
16  font-family: consolas;
17}
18tt {
19  font-family: consolas;
20}
21li {
22  margin-top: 0.5em;
23}
24q {
25  font-style: italic; 
26}
27.break {
28  page-break-before: always;
29}
30@page {
31  size: a4 landscape;
32}
33@page {
34  @bottom-left {
35       content: "Julian Reschke, greenbytes";
36  }
37  @bottom-right {
38       content: counter(page);
39  }
40  @top-center {
41       content: "IETF 95 - Thoughts on HTTP Header Field Parsing";
42  }
43}
44    </style>
45  </head>
46  <body>
47    <h1>IETF 95 - Thoughts on HTTP Header Field Parsing</h1>
48    <p>
49      <a href="mailto:julian.reschke@greenbytes.de">Julian Reschke</a>, greenbytes
50    </p>
51    <p style="font-size: 48pt">
52      <em>Again?</em>
53    </p>
54   
55   
56    <h2 class="break">Background</h2>
57    <ul>
58      <li>HTTPbis WG Work on Content-Disposition (<a href="http://greenbytes.de/tech/webdav/rfc6266.html">RFC 6266</a>)</li>
59      <li>Various HTTPbis WG issues, such as
60        <a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/231">231: Considerations for new headers</a>
61      </li>
62      <li>General Discussions about header compression in the context of HTTP/2</li>
63    </ul>
64   
65    <h2>Problem Statement</h2>
66    <ul>
67      <li>The parsing of many HTTP header fields is <em>hard</em>!</li>
68      <li>Implementations <em>do</em> get it wrong.</li>
69      <li>Extension points not well understood.</li>
70      <li>I18N not well understood and frequently considered too late.</li>
71      <li>We can't fix the past, but we can try to do better.</li>
72    </ul>
73 
74    <p>
75      <em>Most of these slides were done for IETF 81; we haven't made a lot of progress since!</em>
76    </p>
77 
78    <h2 class="break">Example: the List Production and repeating Header Field instances</h2>
79    <pre>  Foo: a
80  Foo: b    </pre>
81    <p>
82      is equivalent to
83    </p>
84    <pre>  Foo: a, b    </pre>
85    <ul>
86      <li>This is fine for simple stuff like method names.</li>
87      <li>It falls apart when people who define new header fields do not get it (Example: Set-Cookie).</li>
88      <li>It helps for folding multiple instances into one, but <em>not</em> for parsing.</li>
89    </ul>
90    <pre>  If-Match: "strong", W/"weak", "oops, a \"comma\""    </pre>
91 
92    <h2 class="break">Example: the List Production and repeating Header Field instances</h2>
93    <p>
94      Combining list production with structured field syntax:
95    </p>
96    <pre>  WWW-Authenticate = 1#challenge
97  challenge        = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
98  auth-param       = token BWS "=" BWS ( token / quoted-string )</pre>
99    <p>
100      Example:
101    </p>
102    <pre>  WWW-Authenticate: Newauth realm="newauth";
103    test="oh, a \"comma\""; foo=a'b'c, Basic realm="basic"
104    </pre>
105
106    <h2 class="break">Example: Parameters - Whitespace, Quoting</h2>
107    <pre>  param = token "=" ( token / quoted-string )    </pre>
108    <pre>  foo=bar; foo='bar'; foo="bar"; foo = "bar"    </pre>
109    <ul>
110      <li>Whitespace sometimes allowed, sometimes not (partly due to confusion about implied LWS).</li>
111      <li>Lots of confused parsers.</li>
112      <li>Single quote <em>is</em> used in <tt>token</tt> values, thus is <em>not</em> available for quoting.</li>
113      <li>Definitions special-case the right hand side for individual parameter names, generic
114      parsers can't do that (example: <a href="http://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.5">RFC 5988</a> disallows token form for <tt>title</tt>, uses
115      double quotes for <tt>quoted-mt</tt> without making it a <tt>quoted-string</tt>).</li>
116      <li>Empty parameters ("; ;") usually not allowed, but accepted in practice.</li>
117    </ul>
118
119    <h2 class="break">Proposals <em>(2011)</em></h2>
120    <ul>
121      <li>Test Cases. Examples. Lots.</li>
122      <li>Make existing syntax more consistent where we can (fix mistakes where possible, discourage generating useless whitespace, require
123      recipients to deal with it nevertheless).</li>
124      <li>Encourage authors of new header fields to re-use existing syntax and to think about extensibility. <em>(done in RFC 7231)</em></li>
125    </ul>
126
127    <h2 class="break">Proposals <em>(2014)</em></h2>
128    <p>
129      For existing header fields (including those in the base specs):
130    </p>
131    <ul>
132      <li>
133        Write test cases.
134      </li>
135      <li>
136        Raise bug reports.
137      </li>
138      <li>
139        Try to refactor parsing code everywhere to increase the amount of shared code between header fields.
140      </li>
141      <li>
142        Feed back the results of this into the RFC723*bis revision process.
143      </li>
144    </ul>
145   
146    <h2 class="break">Proposals <em>(2014)</em> (continued)</h2>
147    <p>
148      Thought experiment in draft-reschke-http-jfv: what if header field values would use JSON?
149    </p>
150    <pre>  WWW-Authenticate: { "Newauth" : {
151                                  "realm": "newauth",
152                                  "test": "oh, a \"comma\"",
153                                  "foo": "a'b'c" }},
154                    { "Basic" : { "realm": "basic" }}
155    </pre>
156    <ul>
157      <li>
158        unified data model: JSON array (implied "[ ... ]")
159      </li>
160      <li>
161        single parser
162      </li>
163      <li>
164        I18N solved once for all
165      </li>
166      <li>
167        list syntax a friend, not an interop problem
168      </li>
169      <li>
170        potential wins in new HTTP wire formats
171      </li>
172    </ul>
173    <p>
174      But:
175    </p>
176    <ul>
177      <li>
178        Chatty when compared to homegrown syntax: maybe a case for a more concise notation for JSON?
179      </li>
180      <li>
181        An alternative would be "JSON object" with implied "{ .. }", but that variant loses the list notation win.
182      </li>
183    </ul>
184   
185    <h2 class="break">Links</h2>
186    <ul>
187      <li>JSON Encoding for Header Field Values - <a href="http://greenbytes.de/tech/webdav/draft-reschke-http-jfv-03.html">draft-reschke-http-jfv-03</a></li>
188    </ul>
189  </body>
190</html>
Note: See TracBrowser for help on using the repository browser.