- From: Anne van Kesteren <notifications@github.com>
- Date: Fri, 13 Dec 2019 05:34:55 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/983/review/331867405@github.com>
annevk commented on this pull request. Thanks, so the one question I have is whether we want to further map a structured header value to an Infra value? I suppose we can add something like that later if there's a real need as well. > @@ -584,10 +585,32 @@ pair in a <a for=/>header list</a> <var>list</var>, run these steps: <li><p><a for="header list">Set</a> <var>name</var>/<var>serializedValue</var> in <var>list</var>. </ol> -<p class="note"><a>Structured header values</a> are defined as objects which HTTP can (eventually) -serialize in interesting and efficient ways. For the moment, Fetch only supports setting these -objects in <a for=/>header lists</a> by serializing them. In the future the fact that they are -objects might be preserved end-to-end. [[!HEADER-STRUCTURE]] +<p>To +<dfn export for="header list" id=concept-header-list-get-structured-header>get a structured header</dfn> +given a <var>name</var> and a <var>type</var> from a <a for=/>header list</a> <var>list</var>, run +these steps: + +<ol> + <li><p>If <var>type</var> is not one of "<code>dictionary</code>", "<code>list</code>", or + "<code>item</code>", return failure. This should probably be an assert, right? At least until we have an API and at that point we could use an enum on the IDL boundary to enforce it. > @@ -584,10 +585,32 @@ pair in a <a for=/>header list</a> <var>list</var>, run these steps: <li><p><a for="header list">Set</a> <var>name</var>/<var>serializedValue</var> in <var>list</var>. </ol> -<p class="note"><a>Structured header values</a> are defined as objects which HTTP can (eventually) -serialize in interesting and efficient ways. For the moment, Fetch only supports setting these -objects in <a for=/>header lists</a> by serializing them. In the future the fact that they are -objects might be preserved end-to-end. [[!HEADER-STRUCTURE]] +<p>To +<dfn export for="header list" id=concept-header-list-get-structured-header>get a structured header</dfn> +given a <var>name</var> and a <var>type</var> from a <a for=/>header list</a> <var>list</var>, run +these steps: + +<ol> + <li><p>If <var>type</var> is not one of "<code>dictionary</code>", "<code>list</code>", or + "<code>item</code>", return failure. + <li><p>Let <var>value</var> be the result of <a for="header list">getting</a> <var>name</var> from + <var>list</var>. + <li><p>If <var>value</var> is null, return null. ```suggestion <li><p>If <var>value</var> is null, then return null. ``` > + <li><p>If <var>type</var> is not one of "<code>dictionary</code>", "<code>list</code>", or + "<code>item</code>", return failure. + <li><p>Let <var>value</var> be the result of <a for="header list">getting</a> <var>name</var> from + <var>list</var>. + <li><p>If <var>value</var> is null, return null. + <li><p>Let <var>result</var> be the result of executing the <a>parsing structured headers</a> + algorithm with <var ignore>input_string</var> set to <var>value</var>, and + <var ignore>header_type</var> set to <var>type</var>. + <li><p>If parsing failed, return failure. + <li><p>Return <var>result</var>. +</ol> + +<p class=note><a>Structured header values</a> are defined as objects which HTTP can (eventually) +serialize in interesting and efficient ways. For the moment, Fetch only supports <a for=/>header</a> +<a for=header>values</a> as <a for=/>byte sequences</a>, which means that these objects can be set +in <a for=/>header lists</a> only via serialization, and they can be obtained from <a for=/>header Please keep elements like `<a>` on a single line. > -objects might be preserved end-to-end. [[!HEADER-STRUCTURE]] +<p>To +<dfn export for="header list" id=concept-header-list-get-structured-header>get a structured header</dfn> +given a <var>name</var> and a <var>type</var> from a <a for=/>header list</a> <var>list</var>, run +these steps: + +<ol> + <li><p>If <var>type</var> is not one of "<code>dictionary</code>", "<code>list</code>", or + "<code>item</code>", return failure. + <li><p>Let <var>value</var> be the result of <a for="header list">getting</a> <var>name</var> from + <var>list</var>. + <li><p>If <var>value</var> is null, return null. + <li><p>Let <var>result</var> be the result of executing the <a>parsing structured headers</a> + algorithm with <var ignore>input_string</var> set to <var>value</var>, and + <var ignore>header_type</var> set to <var>type</var>. + <li><p>If parsing failed, return failure. ```suggestion <li><p>If parsing failed, then return failure. ``` > + <li><p>If <var>value</var> is null, return null. + <li><p>Let <var>result</var> be the result of executing the <a>parsing structured headers</a> + algorithm with <var ignore>input_string</var> set to <var>value</var>, and + <var ignore>header_type</var> set to <var>type</var>. + <li><p>If parsing failed, return failure. + <li><p>Return <var>result</var>. +</ol> + +<p class=note><a>Structured header values</a> are defined as objects which HTTP can (eventually) +serialize in interesting and efficient ways. For the moment, Fetch only supports <a for=/>header</a> +<a for=header>values</a> as <a for=/>byte sequences</a>, which means that these objects can be set +in <a for=/>header lists</a> only via serialization, and they can be obtained from <a for=/>header +lists</a> only by parsing. In the future the fact that they are objects might be preserved +end-to-end. [[!HEADER-STRUCTURE]] + +</div> It seems this and the newline before it were added accidentally? Or is this fixing an existing mistake? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/983#pullrequestreview-331867405
Received on Friday, 13 December 2019 13:34:58 UTC