source: wg_materials/ietf90/ietf-90-httpbis-header-field-parsing.xhtml @ 2730

Last change on this file since 2730 was 2729, checked in by julian.reschke@…, 9 years ago

update presentations
  • Property svn:executable set to *
File size: 6.9 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 90 - 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 90 - Thoughts on HTTP Header Field Parsing";
42  }
43}
44    </style>
45  </head>
46  <body>
47    <h1>IETF 90 - Thoughts on HTTP Header Field Parsing</h1>
48    <p>
49      <a href="mailto:julian.reschke@greenbytes.de">Julian Reschke</a>, greenbytes
50    </p>
51   
52    <h2 class="break">Background</h2>
53    <ul>
54      <li>HTTPbis WG Work on Content-Disposition (<a href="http://greenbytes.de/tech/webdav/rfc6266.html">RFC 6266</a>)</li>
55      <li>Various HTTPbis WG issues, such as
56        <a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/231">231: Considerations for new headers</a>
57      </li>
58      <li>General Discussions about header compression in the context of HTTP/2</li>
59    </ul>
60   
61    <h2>Problem Statement</h2>
62    <ul>
63      <li>The parsing of many HTTP header fields is <em>hard</em>!</li>
64      <li>Implementations <em>do</em> get it wrong.</li>
65      <li>Extension points not well understood.</li>
66      <li>I18N not well understood and frequently considered too late.</li>
67      <li>We can't fix the past, but we can try to do better.</li>
68    </ul>
69 
70    <p>
71      <em>Most of these slides were done for IETF 81; we haven't made a lot of progress since!</em>
72    </p>
73 
74    <h2 class="break">Example: the List Production and repeating Header Field instances</h2>
75    <pre>  Foo: a
76  Foo: b    </pre>
77    <p>
78      is equivalent to
79    </p>
80    <pre>  Foo: a, b    </pre>
81    <ul>
82      <li>This is fine for simple stuff like method names.</li>
83      <li>It falls apart when people who define new header fields do not get it (Example: Set-Cookie).</li>
84      <li>It helps for folding multiple instances into one, but <em>not</em> for parsing.</li>
85    </ul>
86    <pre>  If-Match: "strong", W/"weak", "oops, a \"comma\""    </pre>
87 
88    <h2 class="break">Example: the List Production and repeating Header Field instances</h2>
89    <p>
90      Combining list production with structured field syntax:
91    </p>
92    <pre>  WWW-Authenticate = 1#challenge
93  challenge        = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
94  auth-param       = token BWS "=" BWS ( token / quoted-string )</pre>
95    <p>
96      Example:
97    </p>
98    <pre>  WWW-Authenticate: Newauth realm="newauth";
99    test="oh, a \"comma\""; foo=a'b'c, Basic realm="basic"
100    </pre>
101
102    <h2 class="break">Example: Parameters - Whitespace, Quoting</h2>
103    <pre>  param = token "=" ( token / quoted-string )    </pre>
104    <pre>  foo=bar; foo='bar'; foo="bar"; foo = "bar"    </pre>
105    <ul>
106      <li>Whitespace sometimes allowed, sometimes not (partly due to confusion about implied LWS).</li>
107      <li>Lots of confused parsers.</li>
108      <li>Single quote <em>is</em> used in <tt>token</tt> values, thus is <em>not</em> available for quoting.</li>
109      <li>Definitions special-case the right hand side for individual parameter names, generic
110      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
111      double quotes for <tt>quoted-mt</tt> without making it a <tt>quoted-string</tt>).</li>
112      <li>Empty parameters ("; ;") usually not allowed, but accepted in practice.</li>
113    </ul>
114
115    <h2 class="break">Proposals <em>(2011)</em></h2>
116    <ul>
117      <li>Test Cases. Examples. Lots.</li>
118      <li>Make existing syntax more consistent where we can (fix mistakes where possible, discourage generating useless whitespace, require
119      recipients to deal with it nevertheless).</li>
120      <li>Encourage authors of new header fields to re-use existing syntax and to think about extensibility. <em>(done in RFC 7231)</em></li>
121    </ul>
122
123    <h2 class="break">Proposals <em>(2014)</em></h2>
124    <p>
125      For existing header fields (including those in the base specs):
126    </p>
127    <ul>
128      <li>
129        Write test cases.
130      </li>
131      <li>
132        Raise bug reports.
133      </li>
134      <li>
135        Try to refactor parsing code everywhere to increase the amount of shared code between header fields.
136      </li>
137      <li>
138        Feed back the results of this into the RFC723*bis revision process.
139      </li>
140    </ul>
141   
142    <h2 class="break">Proposals <em>(2014)</em> (continued)</h2>
143    <p>
144      Thought experiment in draft-reschke-http-jfv: what if header field values would use JSON?
145    </p>
146    <pre>  WWW-Authenticate: { Newauth : {
147                                  realm: "newauth",
148                                  test: "oh, a \"comma\"",
149                                  foo: "a'b'c" }},
150                    { Basic : { realm: "basic" }}
151    </pre>
152    <ul>
153      <li>
154        unified data model: JSON array (implied "[ ... ]")
155      </li>
156      <li>
157        single parser
158      </li>
159      <li>
160        I18N solved once for all
161      </li>
162      <li>
163        list syntax a friend, not an interop problem
164      </li>
165      <li>
166        potential wins in new HTTP wire formats
167      </li>
168    </ul>
169    <p>
170      But:
171    </p>
172    <ul>
173      <li>
174        Chatty when compared to homegrown syntax: maybe a case for a more concise notation for JSON?
175      </li>
176      <li>
177        An alternative would be "JSON object" with implied "{ .. }", but that variant loses the list notation win.
178      </li>
179    </ul>
180   
181    <h2 class="break">Links</h2>
182    <p>
183      My tests:
184    </p>
185    <ul>
186      <li>Content-Disposition - <a href="http://greenbytes.de/tech/tc2231/">http://greenbytes.de/tech/tc2231/</a></li>
187      <li>Content-Type - <a href="http://greenbytes.de/tech/tc/httpcontenttype/">http://greenbytes.de/tech/tc/httpcontenttype/</a></li>
188      <li>JSON Encoding for Header Field Values - <a href="http://greenbytes.de/tech/webdav/draft-reschke-http-jfv-00.html">draft-reschke-http-jfv-00</a></li>
189      <li>Link - <a href="http://greenbytes.de/tech/tc/httplink/">http://greenbytes.de/tech/tc/httplink/</a></li>
190      <li>WWW-Authenticate - <a href="http://greenbytes.de/tech/tc/httpauth/">http://greenbytes.de/tech/tc/httpauth/</a></li>
191    </ul>
192    <p>
193      ...and then there's also <a href="http://redbot.org/">http://redbot.org/</a>.
194    </p>
195
196  </body>
197</html>
Note: See TracBrowser for help on using the repository browser.