What would you like to be improved?
The WARC writer in external/warc.
How should we improve?
The WARC-Protocol headers holding the HTTP protocol and SSL/TLS versions should follow the current WARC field proposals
The current form
WARC-Protocol: h2,TLS_1_3,TLS_AES_128_GCM_SHA256
should become
WARC-Protocol: h2
WARC-Protocol: TLS_1_3
WARC-Cipher-Suite: TLS_AES_128_GCM_SHA256
That is: split the values and put them separately into the two headers.
See also:
The WARC-Protocol field proposal has changed since 2020. The WARC-Cipher-Suite field was proposed in 2023. The proposals have been settled and both fields are now used in multiple projects / WARC writers.
Unfortunately, both protocol-related versions and cipher suite are hold below the same key (PROTOCOL_VERSIONS_KEY) in metadata. Are there any objections to split protocol version and cipher suite over two containers? This would make the implementation easier, not requiring pattern matching to split the cipher suite value apart.
What would you like to be improved?
The WARC writer in external/warc.
How should we improve?
The
WARC-Protocolheaders holding the HTTP protocol and SSL/TLS versions should follow the current WARC field proposalsThe current form
should become
That is: split the values and put them separately into the two headers.
See also:
WARC-Protocolheader in 2020.The
WARC-Protocolfield proposal has changed since 2020. TheWARC-Cipher-Suitefield was proposed in 2023. The proposals have been settled and both fields are now used in multiple projects / WARC writers.Unfortunately, both protocol-related versions and cipher suite are hold below the same key (PROTOCOL_VERSIONS_KEY) in metadata. Are there any objections to split protocol version and cipher suite over two containers? This would make the implementation easier, not requiring pattern matching to split the cipher suite value apart.