You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It doesn't seem to be explicitly specified anywhere, but when exporting a HAR file for HTTP/2 traffic, it seems that most clients (e.g. Chrome) do include the HTTP/2 pseudo-headers in the header data. These are headers like :authority and :method.
This makes sense for HAR files, when you want an accurate recording of the full traffic details, but these shouldn't be included in HTTP snippets imo. Most clients will reject them completely, for example this curl command generated by httpsnippet will always fail, even though the original request worked fine:
These headers are basically duplicating the method & URL parts, which we include separately anyway. They're just a detail of how the method & URL are sent in HTTP/2. They also won't work because I think in every snippet here we're sending pure HTTP/1 requests, where these are generally illegal header names anyway (which I guess is why curl fails here).
I would suggest we filter these out, i.e. drop all headers starting with : when we load data from the HAR. That will never happen in HTTP/1 traffic, and in HTTP/2 traffic it's almost always redundant, and the rare cases where it's not are very weird (I think sending a request to one domain but with a :authority header for different domain is the only possible example?).
Alternatively, we could try to fully translate HTTP/2 data back into the exactly equivalent HTTP/1 requests. I wrote a blog post about that a while back here: https://httptoolkit.tech/blog/translating-http-2-into-http-1/#translating-one-to-the-other. That would just be the first HTTP/2 -> HTTP/1 list, under 'Translating one to the other', and only half are relevant, so I think it's relatively simple, but it's still more complicated than just dropping the headers, and it might plausibly have other side effects.
What do you think?
The text was updated successfully, but these errors were encountered:
It doesn't seem to be explicitly specified anywhere, but when exporting a HAR file for HTTP/2 traffic, it seems that most clients (e.g. Chrome) do include the HTTP/2 pseudo-headers in the header data. These are headers like
:authority
and:method
.This makes sense for HAR files, when you want an accurate recording of the full traffic details, but these shouldn't be included in HTTP snippets imo. Most clients will reject them completely, for example this curl command generated by httpsnippet will always fail, even though the original request worked fine:
These headers are basically duplicating the method & URL parts, which we include separately anyway. They're just a detail of how the method & URL are sent in HTTP/2. They also won't work because I think in every snippet here we're sending pure HTTP/1 requests, where these are generally illegal header names anyway (which I guess is why curl fails here).
I would suggest we filter these out, i.e. drop all headers starting with
:
when we load data from the HAR. That will never happen in HTTP/1 traffic, and in HTTP/2 traffic it's almost always redundant, and the rare cases where it's not are very weird (I think sending a request to one domain but with a:authority
header for different domain is the only possible example?).Alternatively, we could try to fully translate HTTP/2 data back into the exactly equivalent HTTP/1 requests. I wrote a blog post about that a while back here: https://httptoolkit.tech/blog/translating-http-2-into-http-1/#translating-one-to-the-other. That would just be the first HTTP/2 -> HTTP/1 list, under 'Translating one to the other', and only half are relevant, so I think it's relatively simple, but it's still more complicated than just dropping the headers, and it might plausibly have other side effects.
What do you think?
The text was updated successfully, but these errors were encountered: