WSP

空白 (電子メール、HTTP)

[12] 電子メールヘッダー内では元来あらゆる字句間に空白注釈が認められていました。 電子メールに強い影響を受けた HTTP でも、多くの場所で空白を認めていました。 電子メールでも HTTP でも、仕様の改訂により徐々に空白の使用方法が限定的になってきています。

電子メールにおける空白

[1] Linear white space (線形空白)。

[2] RFC 822 で使われておりましたが、 RFC 2822 では FWS (や CFWS) に全面的に置き換えられています。

[55] FWS は、空白を表しています。 U+0020U+0009 を使うことができるのに加えて、 直後に U+0020U+0009 が続く場合に、 U+000D U+000A (CRLF) を使うことができます。これは折り畳みと呼ばれているもので、 1つのヘッダーを複数で表したい時に使います。

[56] CFWS は、 FWS に加えて、注釈を使うことが認められるものです。

[5] >>4 3.1.4. は字句間に linear-white-space を挿入して良いとしています。

[7] >>6U+0009 の使用は勧められない (discouraged) とされています。

[10] RFC 2822 では WSP のみの行の使用は禁止されていますが、理解できなければなりません >>9

折り畳み

[21] 折り畳まれた2行目以降の部分に : という文字が含まれていると、へんちくりんな MTA が勝手にその直後に SP を挿入しちゃったりすることがあるんだそうです。 (そんなのが21世紀になっても生き残っているとは!)

[22] >>21 参考 : はじめてのにっき(2003-09-05) http://hajimeteno.alib.jp/diary/?date=20030905, IW:mew-dist:23997

[23] >>21-22 特に multipart/*boundary 引数なんかがそれに引っ掛かると深刻なので、 Mew では境界文字列に : があったら _ に置き換えるみたいです。

HTTP における空白

[13] HTTP における空白は、 OWS (省略可能空白)、 RWS (必須空白)、BWS (「悪い」空白) に分類されています >>31

[32] また、行折り畳み (line folding) として、 改行空白を続けることで欄値を複数行に分割することもできました。 ただし現在はその生成が禁止されています。

仕様書

文脈

[39] 空白欄値中の色々な場所で認められています。場所により、 OWSRWSBWS のいずれかが指定されています。 SP と指定されていることもあります。

[25] 欄値には行折り畳み (obs-fold) が含まれることがあります >>24。ただし廃止された構文とされており、 生成してはなりません。

[41] message/http 以外では非推奨 (deprecated) >>40message/http を意図した場合を除き禁止 >>40 ともされており、完全に禁止されているわけではないとも解釈できます。

[43] 次の場面では SP そのものが構文上求められています。

構文

[34] 空白 (OWS, RWS, BWS) は、いずれも任意の文字数の SPHTAB です >>31

[35] OWS は、可読性のために好ましい時は SP 1つとして生成するべきです。 それ以外では、非妥当だったり望まなかったりするプロトコル要素をその場でメッセージをフィルタリングするために必要な場合を除き、 生成するべきではありません>>31

[36] 後者がいつなのかよくわかりませんが...
[18] RFC 6265, RFC 6454 の定義では、OWS は生成しないか、 または単一の SP とするべきです >>14, >>15
  1. ?
    1. U+0020

[37] RWS は、 SP 1つとして生成するべきです >>31。 そうでなくても必ず1文字は必要です >>31

  1. U+0020

[38] BWS は、生成してはならず受信者は解釈の前に削除しなければなりません >>31

[26] 行折り畳みは、 CRLF の後1文字以上の SP または HTAB とされています >>24

  1. U+000D
  2. U+000A
  3. +
    1. |
      1. U+0020
      2. U+0009

意味

[19] OWS は零個以上の線形空白が現れて良い場所で使います。 >>14, >>15

処理モデル

[42] は、 message/http 以外の要求メッセージ行折り畳みを受信した場合、 400 を (できれば行折り畳みは受け付けられない旨の表現と共に) 返すか、または行折り畳みを1つ以上の SP に置き換えてから解釈するか、下流転送するかしなければなりません >>31

[401] 関門は、 message/http 以外の応答メッセージ行折り畳みを受信した場合、 そのメッセージを捨てて 502 を (できれば行折り畳みは受け付けられない旨の表現と共に) 返すか、 または行折り畳みを1つ以上の SP に置き換えてから解釈するか、下流転送するかしなければなりません >>31

[503] 利用者エージェントは、 message/http 以外の応答メッセージ行折り畳みを受信した場合、 行折り畳みを1つ以上の SP に置き換えてから解釈しなければなりません >>31

[20] RFC 6265, RFC 6454 の定義では、複数の OWS オクテットは、 欄値を解釈する前に、 または下流に転送する前に単一の SP、または同じ個数の SP に置換するべきです>>14

歴史

[27] RFC 2616 世代までは、構文上 LWS ではなく SP を使って定義されているところでは、行折り畳みが使えないとも解釈できました。

例えば、

... は SP を使って定義されています。

[504] RFC 7230行折り畳みSP に置き換えてから解釈が行われるとしており、 >>27 のような箇所でも行折り畳みが使えると明確になっています。

[44] 開始行ヘッダーではありませんから、そもそも行折り畳みは使えません。

[33] RFC 7230 の開発途中に出版された RFC 6265, RFC 6454 は、 RFC 7230 とは少し違った OWS を定義していました。 いずれも定義は微妙に異なっていますが、実態としては同じような規定です。

[16] OWSABNF 構文 >>14
   OWS            = *( SP / HTAB / obs-fold )
                  ; "optional" whitespace
   obs-fold       = CRLF ( SP / HTAB )
                  ; obsolete line folding
[17] OWSABNF 構文 >>15
   OWS            = *( [ obs-fold ] WSP )
                    ; "optional" whitespace
   obs-fold       = CRLF

CGI における空白

[1]

      SP            = <space character>
      HT            = <horizontal tab character>
      NL            = <newline>
      LWSP          = SP | HT | NL

[3] CGIでは実際のビット列システム定義とされています。特に、 NL は1バイトである必要がないことが明記されています。

[30] CGI応答では折り畳みは認められていません。

仕様書

[505] Introduce concept-header-list-combine for XMLHttpRequest · 6965d6e · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/6965d6e4e9cc2705f1ca2b230a77747cc1fa2626

[45] Reference the new HTTP RFCs. Normalize header values. Fixes #99, #100… · whatwg/fetch@6c00fe2 ( 版) https://github.com/whatwg/fetch/commit/6c00fe28e7a361d2b7e0dda776ebccfaa4c439a5

[46] Fetch Standard ( 版) https://fetch.spec.whatwg.org/#http-whitespace-bytes

[47] Wireless Application Protocol Wireless Session Protocol Specification ( 版) http://technical.openmobilealliance.org/tech/affiliates/wap/WAP-230-WSP-20010705-a.pdf

[48] Use `,` rather than `, ` for the combine operation (annevk著, ) https://github.com/whatwg/fetch/commit/c21f8bd50ef9e919e6b1003a6dfbe29a7195d57a

[49] PSGI - search.cpan.org () http://search.cpan.org/dist/PSGI/PSGI.pod

If there are multiple header lines sent with the same key, the server should treat them as if they were sent in one line and combine them with , , as in RFC 2616.

[50] Stop lowercasing header names (annevk著, ) https://github.com/whatwg/fetch/commit/5869c43a27fff06c6dfc228fe1288018f7f2168d

[51] Change combine and combined value to use 0x2C 0x20 (#504) (annevk著, ) https://github.com/whatwg/fetch/commit/d9307bde55a32dee1a82207202f712fc3c8fde8b

[52] Align header handling with Fetch (annevk著, ) https://github.com/whatwg/xhr/commit/a6e79810a381b8e336570da797967c4b34e0c6b1

[53] Get multiple headers as an aray rather than a combined value? · Issue #506 · whatwg/fetch () https://github.com/whatwg/fetch/issues/506

[54] Release Notes for Safari Technology Preview 26 | WebKit () https://webkit.org/blog/7474/release-notes-for-safari-technology-preview-26/

[57] Define parsing for X-Content-Type-Options: nosniff in detail (annevk著, ) https://github.com/whatwg/fetch/commit/32c7b1c76a43ea96b8663628b891b339553ae114

[58] What does "combined value" return for a name not in the header list? · Issue #752 · whatwg/fetch () https://github.com/whatwg/fetch/issues/752

[59] Define parsing for X-Content-Type-Options in detail by annevk · Pull Request #818 · whatwg/fetch () https://github.com/whatwg/fetch/pull/818

[60] Add HTTP whitespace back for MIME types (annevk著, ) https://github.com/whatwg/fetch/commit/a243f1f8af10f78ead83953bfb0f1c6ee21cb8a1

[61] Add HTTP whitespace back for MIME types by annevk · Pull Request #828 · whatwg/fetch () https://github.com/whatwg/fetch/pull/828

[62] Use HTTP rather than ASCII whitespace by annevk · Pull Request #90 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/pull/90

[63] Use HTTP whitespace rather than ASCII whitespace (annevk著, ) https://github.com/whatwg/mimesniff/commit/126286ab2dcf3e2d541349ed93539a88bf394ad5

[64] MIME type parsing: stop treating 0x0C as whitespace · Issue #89 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/89