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

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.

I'll take a pass at better specifying the CORS-readable security
mitigations over the next few days but I wanted to get the cleaned-up draft
out while I work on beefing that part up. I expect I'll need to be a lot
more thorough about documenting the references to SF field types and other
spec-language considerations but I'll get the core logic nailed down first.

Thanks,

-Pat

On Mon, Jul 3, 2023 at 11:27 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> SNIPping for clarity
>
> On Tue, Jul 4, 2023 at 4:04 AM Patrick Meenan <patmeenan@gmail.com> wrote:
>
>>
>> Sorry, just saw that the tooling going from markdown->ID lost some of the
>> breakpoints (and I need to figure out tables so I can better represent a
>> few of the sections).  The one thing that I don't know is what the best
>> practices are for sample HTTP headers that don't fit on a single line and
>> if it is ok to wrap them or if it is better to shorten the header value to
>> make it fit (might require an invalid string length for a hash but could be
>> clearer to read).
>>
>
> Both the Signature and Digest specs have long line problems and manage the
> wrapping using RFC8792 notation, so I'd recommend that. Here's an example:
> https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-digest-headers.md?plain=1#L266-L272
>

Received on Wednesday, 5 July 2023 17:58:34 UTC