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 - Client-Initiated Content-Encoding</title>
|
---|
6 | <style type="text/css">
|
---|
7 | body {
|
---|
8 | color: black;
|
---|
9 | font-family: cambria, helvetica, arial, sans-serif;
|
---|
10 | font-size: 18pt;
|
---|
11 | }
|
---|
12 | h1 {
|
---|
13 | font-size: 36pt;
|
---|
14 | }
|
---|
15 | li {
|
---|
16 | margin-top: 0.5em;
|
---|
17 | }
|
---|
18 | q {
|
---|
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 90 - Client-Initiated Content-Encoding";
|
---|
36 | }
|
---|
37 | }
|
---|
38 | </style>
|
---|
39 | </head>
|
---|
40 | <body>
|
---|
41 | <h1>IETF 90 - Client-Initiated Content-Encoding</h1>
|
---|
42 | <p>
|
---|
43 | <a href="mailto:julian.reschke@greenbytes.de">Julian Reschke</a>, greenbytes
|
---|
44 | </p>
|
---|
45 |
|
---|
46 | <h2 class="break">What problem does it solve?</h2>
|
---|
47 | <p>
|
---|
48 | HTTP/1.1 clients already can use content codings such as "gzip" in requests, but
|
---|
49 | if a server doesn't play along, it's hard to understand what went wrong.
|
---|
50 | </p>
|
---|
51 | <p>
|
---|
52 | Status code 415 (Unsupported Media Type) can already be used, but
|
---|
53 | the recipient wouldn't know whether the problem was caused by the
|
---|
54 | media type or the content coding, and also would need information
|
---|
55 | about what content codings <em>are</em> supported.
|
---|
56 | </p>
|
---|
57 |
|
---|
58 | <h2>Proposed Solution</h2>
|
---|
59 | <p>
|
---|
60 | Extend "Accept-Encoding" header field to be usable in responses as well.
|
---|
61 | When sent in a 415 response, it would indicate which content codings
|
---|
62 | are supported.
|
---|
63 | </p>
|
---|
64 | <p>
|
---|
65 | See <a href="http://greenbytes.de/tech/webdav/draft-reschke-http-cice-01.html">draft-reschke-http-cice-01</a>.
|
---|
66 | </p>
|
---|
67 | <p>
|
---|
68 | This is a really a tiny, backwards compatible extension to RFC 7231;
|
---|
69 | it might have been part of it if we had thought of it in time.
|
---|
70 | </p>
|
---|
71 |
|
---|
72 | <h2 class="break">To Be Discussed</h2>
|
---|
73 | <p>
|
---|
74 | Also define use in OPTIONS response? Trouble is it might vary
|
---|
75 | be request method.
|
---|
76 | </p>
|
---|
77 | <p>
|
---|
78 | Content codings can be seen as ugly workaround for transfer codings
|
---|
79 | not implemented in practice. Should we try harder to fix <em>that</em>
|
---|
80 | problem?
|
---|
81 | </p>
|
---|
82 | <p>
|
---|
83 | Working Group draft?
|
---|
84 | </p>
|
---|
85 | <p>
|
---|
86 | Once it's a Proposed Standard, it'll be a candidate for inclusion into RFC7231bis.
|
---|
87 | </p>
|
---|
88 | </body>
|
---|
89 | </html>
|
---|