Re: Compression dictionary draft ID - draft-meenan-httpbis-compression-dictionary-00

Thanks everyone for the feedback so far.

I updated the CORS-readability section
<https://www.ietf.org/archive/id/draft-meenan-httpbis-compression-dictionary-04.html#name-response-readability>
to lay out the cases where dictionaries can be stored and where responses
are allowed to be dictionary-compressed.  Most of it is laid out explicitly
and can be done off of the request/response headers but on the browser-side
there is some additional filtering that needs to be done based on the
credentials mode and if Access-Control-Allow-Credentials is in the
response. In that case it links to the fetch spec's CORS processing flow.
I tried to eliminate any links to WHATWG specs but that is the only place I
could find that defines the CORS processing and how it relates to
credentials. I pinged our security team to give it a once-over again to
make sure it covers all of the cases that we are aware of.

I also changed the definition of the Sec-Available-Dictionary
<https://www.ietf.org/archive/id/draft-meenan-httpbis-compression-dictionary-04.html#name-sec-available-dictionary>
request header to not be SF and to lay out the ABNF for the hash since it's
a naked hash string.

I'll see about beefing up the examples for the path
parsing/expansion/matching to cover a lot more cases.

Let me know if there's anything else that either doesn't look quite right
or could use more clarification.

Thanks,

-Pat

On Thu, Jul 6, 2023 at 4:57 AM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Wed, Jul 05, 2023 at 01:58:18PM -0400, Patrick Meenan wrote:
> > Thanks.  I cleaned up the formatting so it should be much easier to read
> > now. I also:
> >
> > - Added the "Vary" header on compressed responses which I had missed on
> my
> > original submission.
> > - Simplified the wildcard matching algorithm to make it a single-pass
> > substring match against the request URL instead of truncating the URL
> after
> > each match.
> > - Cleaned up the IANA considerations section (switched to tables) and
> added
> > the headers.
>
> Quick comments about -03:
>
> - Sec-Available-Dictionary is documented as sf-string, but the example
>   looks like sf-token. I don't think sf-token is enough, what would
>   happen if first byte is in range 00-9F (would cause first character
>   to be digit, which I do not think is legal in sf-token)?
>
> - Why allow illegal (violates section 6.3.1.) match patterns, as opposed
>   to making those impossible to encode? I would understand if that would
>   be a difficult task, but it does not seem to be so.
>
> - And might be good idea to have at least one example of how relative
>   match paths behave. Or how matches behave in presence of queries.
>
>
>
>
> -Ilari
>
>