source: wg_materials/ietf81/ietf-81-header-field-parsing.xhtml @ 1336

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

minor editorial fixes to slides

  • Property svn:executable set to *
File size: 4.6 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 81 - Thoughts on HTTP Header Field Parsing</title>
6    <style type="text/css">
7body {
8  color: black;
9  font-family: verdana, helvetica, arial, sans-serif;
10  font-size: 18pt;
11}
12h1 {
13  font-size: 36pt;
14}
15li {
16  margin-top: 0.5em;
17}
18q {
19  font-style: italic; 
20}
21.break {
22  page-break-before: always;
23}
24@page {
25  size: a4 landscape;
26}
27@page {
28  @bottom-left {
29       content: "Julian Reschke, greenbytes";
30  }
31  @bottom-right {
32       content: counter(page);
33  }
34  @top-center {
35       content: "IETF 81 - Thoughts on HTTP Header Field Parsing";
36  }
37}
38    </style>
39  </head>
40  <body>
41    <h1>IETF 81 - Thoughts on HTTP Header Field Parsing</h1>
42    <p>
43      <a href="mailto:julian.reschke@greenbytes.de">Julian Reschke</a>, greenbytes
44    </p>
45 
46    <h2 class="break">Background</h2>
47    <ul>
48      <li>HTTPbis WG Work on Content-Disposition (now <a href="http://greenbytes.de/tech/webdav/rfc6266.html">RFC 6266</a>)</li>
49      <li>Various HTTPbis WG issues, such as
50        <a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/231">231: Considerations for new headers</a>
51      </li>
52    </ul>
53   
54    <h2>Problem Statement</h2>
55    <ul>
56      <li>The parsing of many HTTP header fields is <em>hard</em>!</li>
57      <li>Implementations <em>do</em> get it wrong.</li>
58      <li>Extension points not well understood.</li>
59      <li>I18N not well understood and frequently considered too late.</li>
60      <li>We can't fix the past, but we can try to do better.</li>
61    </ul>
62 
63    <h2 class="break">Example: the List Production and repeating Header Field instances</h2>
64    <pre>  Foo: a
65  Foo: b    </pre>
66    <p>
67      is equivalent to
68    </p>
69    <pre>  Foo: a, b    </pre>
70    <ul>
71      <li>This is fine for simple stuff like method names.</li>
72      <li>It falls apart when people who define new header fields do not get it (Example: Set-Cookie).</li>
73      <li>It helps for folding multiple instances into one, but <em>not</em> for parsing.</li>
74    </ul>
75    <pre>  If-Match: "strong",W/"weak","oops, we should have thought of that"    </pre>
76 
77    <h2 class="break">Example: the List Production and repeating Header Field instances</h2>
78    <p>
79      Combining list production with structured field syntax:
80    </p>
81    <pre>  WWW-Authenticate = 1#challenge
82  challenge        = auth-scheme 1*SP 1#auth-param
83  auth-param       = token "=" ( token / quoted-string )</pre>
84    <p>
85      Example:
86    </p>
87    <pre>  WWW-Authenticate: Newauth realm="newauth";
88    test="oh, a \"comma\""; foo=a'b'c, Basic realm="basic"
89    </pre>
90
91    <h2 class="break">Example: Parameters - Whitespace, Quoting</h2>
92    <pre>  param = token "=" ( token / quoted-string )    </pre>
93    <pre>  foo=bar; foo='bar'; foo="bar"; foo = "bar"    </pre>
94    <ul>
95      <li>Whitespace sometimes allowed, sometimes not.</li>
96      <li>Lots of confused parsers.</li>
97      <li>Single quote <em>is</em> used in <tt>token</tt> values, thus is <em>not</em> available for quoting.</li>
98      <li>Definitions special-case the right hand side for individual parameter names, generic
99      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
100      double quotes for <tt>quoted-mt</tt> without making it a <tt>quoted-string</tt>)</li>
101    </ul>
102
103    <h2 class="break">Proposals</h2>
104    <ul>
105      <li>Test Cases. Examples. Lots.</li>
106      <li>Make existing syntax more consistent where we can (fix mistakes where possible, discourage generating useless whitespace, require
107      recipients to deal with it nevertheless)</li>
108      <li>Encourage authors of new header fields to re-use existing syntax and to think about extensibility.</li>
109    </ul>
110
111    <h2 class="break">Links</h2>
112    <p>
113      My tests:
114    </p>
115    <ul>
116      <li>Content-Disposition - <a href="http://greenbytes.de/tech/tc2231/">http://greenbytes.de/tech/tc2231/</a></li>
117      <li>Content-Type - <a href="http://greenbytes.de/tech/tc/httpcontenttype/">http://greenbytes.de/tech/tc/httpcontenttype/</a></li>
118      <li>Link - <a href="http://greenbytes.de/tech/tc/httplink/">http://greenbytes.de/tech/tc/httplink/</a></li>
119      <li>WWW-Authenticate - <a href="http://greenbytes.de/tech/tc/httpauth/">http://greenbytes.de/tech/tc/httpauth/</a></li>
120    </ul>
121    <p>
122      ...and then there's also <a href="http://redbot.org/">http://redbot.org/</a>.
123    </p>
124
125  </body>
126</html>
Note: See TracBrowser for help on using the repository browser.