Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does WARCreate handle preserving HTTP/2 communication? #103

Open
machawk1 opened this issue Jan 30, 2018 · 5 comments
Open

How does WARCreate handle preserving HTTP/2 communication? #103

machawk1 opened this issue Jan 30, 2018 · 5 comments

Comments

@machawk1
Copy link
Owner

The current behavior needs to be documented. Per the WARC/1.1 spec, there is no documented "right way" but identifying the current approaches would be useful and help to guide how it might be done.

@machawk1 machawk1 changed the title How does WARCreate handle HTTP/2 communication? How does WARCreate handle preserving HTTP/2 communication? Jan 30, 2018
@ibnesayeed
Copy link
Collaborator

For the reference iipc/warc-specifications#15

@machawk1
Copy link
Owner Author

machawk1 commented Jan 30, 2018

That discussion was part of the impetus for creating this issue, @ibnesayeed. This issue is about determining what the current behavior is. The result of that can be cross-referenced with other discussions on the correct representation.

@N0taN3rd
Copy link
Collaborator

N0taN3rd commented Jan 30, 2018

@machawk1 I would assume the "right" way would be to turn the HTTP/2 protocols into HTTP/1.1.

Reasoning:

  • currently no existing replay system handles replay of HTTP/2
  • tools like warcreate and Squidwarc see headers as HTTP/2 but see the bodies as if they were sent over HTTP/1.1 (not the individual parts of the stream)

@machawk1
Copy link
Owner Author

@N0taN3rd Maybe a conversion record is more suitable for the HTTP/1.1 derivative while still maintaining the original payload while replay systems (and the WARC spec) catch up.

@ibnesayeed
Copy link
Collaborator

I would agree with @machawk1, because as an archivist you never want to lose information that might be useful later just because current tools do not support something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants