IETF における ABNF とプロトコルパーサの話 / ABNF for Protocol Parser @ IETF

Transcript

1. #授業_study

2. None
3. None

4. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |

   0 | 1 | 0 | +---+---+-----------------------+ | H | Name Length (7+) | +---+---------------------------+ | Name String (Length octets) | +---+---------------------------+ | H | Value Length (7+) | +---+---------------------------+ | Value String (Length octets) | +-------------------------------+ Request = Request-Line *(( general-header | request-header | entity-header ) CRLF) CRLF [ message-body ] Response = Status-Line *(( general-header | response-header | entity-header ) CRLF) CRLF [ message-body ] QUIC, HTTP2, HPAC, TLS etc Easy and effective to parse HTTP/1.1, JSON, XML, SDP etc
5. None

6. Request = Request-Line *(( general-header | request-header | entity-header )

   CRLF) CRLF [ message-body ] POST / HTTP/1.1↵ Host: example.com↵ Content-Length: 256↵ Content-Type: application/json↵ ↵ {"hello": "world", ...} • BNF: 「これの次はこれが来る」という規則に よって文法を定義するやつ • ABNF: BNF の IETF 版 [RFC 5234] • 厳密に定義されてるのでここから機械的に処 理系が実装できそう • 機械的に関数に落とし込み、それを組み合わ せる再起降下パーサを書けばすぐ実装できそ う

7. • ラジオを聞きながら ABNF を何も考えずに機械的に関数に落とす • 出来上がった関数にテキストを食わせるとなんか動く • 楽しい 書いたもの: JSON,

   HTTP, URL, SDP, SFV etc (一度覚えるとネタは無限)
8. None

9. HTTP Header の Value の構造はそれぞれバラバラだった > Set-Cookie: max-age=100; Secure; HttpOnly;

   SameSite=Lax; • ここに List / Dict などの構造を定義しようという仕様。 • かつて JSON にしようとしたがうまく行かなかったもの。 • すでにいくつかの仕様が参照中 ◦ Signing HTTP Message ◦ Trust Token

10. https://jxck.github.io/structured-field-values/demo.html

11. None
12. None

13. RFC Editor State (RFC なる直 前) に報告したのでみんなで 焦って直すことに。 誰も実装せずに机上の議論だけ で正しい

    ABNF を探す、みんな でパズルを解くような感覚。

14. • 他にも何個か直面した • IPv6 文字列 [RFC Errata Report] • URI

    [RFC Errata Report] • etc etc etc そもそも機械的な検証を経て RFC に乗ってるわけではない ABNF は信用できない？ > RFC 5234 is designed to describe what's valid to produce -- it's not designed as the definitive source for building a perfect parser. そもそもパースよりシリアライズのためのものなんで用途が違うよ --- https://www.rfc-editor.org/errata_search.php?eid=4393
15. None

16. When parsing from HTTP fields, implementations MUST have behavior that

    is indistinguishable from following the algorithms. If there is disagreement between the parsing algorithms and ABNF, the specified algorithms take precedence. このアルゴリズムと同じ感じでパースしろ、あともしアルゴリズムと ABNF で食い違ったらアルゴリズムが正 な。 For serialization to HTTP fields, the ABNF illustrates their expected wire representations, and the algorithms define the recommended way to produce them. Implementations MAY vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm. ABNF の感じでシリアライズしろ。それをするための推奨アルゴリズムはあるけど、さっきのパーサで正しく パースできるなら多少違っても良い。 ABNF で正しく仕様を書くことや、それをもとに互換製のあ る実装を起こすことに、そもそも期待してない感じがある。

17. : 多くの開発者がこの RFC をもとに実装を起こすということは、この仕様の 完成度はそのままインターネットの相互通信における互換性の向上に寄与し、互 換性は安定した運用に直結すると考えられる。また ABNF は構文解析を習得した 技術者にとっては実装の参考として非常に重要な情報源であるため、仮にアルゴ リズムを優先するという仕様であっても、ある程度の精度が保証されていること

    が望ましい。仕様策定者が実装による検証を行っていないのであれば、それを代 行することは自分なりの仕様への貢献と考え、あえて ABNF に忠実な再起降下 パーサを起こし、テストケースを網羅することで、仕様の不備を炙りだすことに 成功した。 : ちなみに、RFC が出たら仕様通りアルゴリズム版リリース予定

18. ドラフト段階で代わりにやるとちょっと役立つかも

19. • 書いてあるアルゴリズムが起こせれば OK ◦ パーサジェネレータとか使わない ◦ そもそも ABNF がそこまで厳密な保証がない ◦

    ABNF は読めれば OK • ABNF が正しいかは要注意 ◦ 実装検証はされてないことが多い ◦ 読むならまず Errata を確認 • でもこれは IETF(Internet Protocol) の話 ◦ プログラミング言語とかはまた別 ◦ あとで学び直すの面倒なので構文解析の授業があったらちゃんと聞いておくと吉

20. バイナリはバイナリでまた別の楽しさがある