nutch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebastian Nagel (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NUTCH-2716) protocol-http: Response headers are not stored for a compressed response
Date Mon, 06 May 2019 15:21:00 GMT

    [ https://issues.apache.org/jira/browse/NUTCH-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833907#comment-16833907
] 

Sebastian Nagel commented on NUTCH-2716:
----------------------------------------

I think removing the headers is not ideal for two reasons:
- the proper solution for WARC files is to archive the misleading headers with a {{X-}} prefix,
see the [discussion on the openwayback list|https://groups.google.com/forum/#!topic/openwayback-dev/vabOfUZhXAs].
Yes, any WARC writer should handle this.
- the headers should be kept as is because there might be other use cases than writing WARC
files, e.g. [some users want to index HTTP headers|https://lists.apache.org/thread.html/cfcd5c45a01b82b527c73cb9d12e2b7982af2ce6165dff20ce52b784@%3Cuser.nutch.apache.org%3E]
and modifications would only cause confusions



> protocol-http: Response headers are not stored for a compressed response
> ------------------------------------------------------------------------
>
>                 Key: NUTCH-2716
>                 URL: https://issues.apache.org/jira/browse/NUTCH-2716
>             Project: Nutch
>          Issue Type: Bug
>          Components: protocol
>    Affects Versions: 1.15
>            Reporter: Yossi Tamari
>            Assignee: Sebastian Nagel
>            Priority: Major
>             Fix For: 1.16
>
>
> Even when store.http.headers=true, the HTTP headers are not saved for a gzipped or deflated
response, because they may contain an incorrect content-length header.
> This causes WARCExporter to generate "resource" (headreless) entries instead of "response"
entries.
> While I can see why reporting the wrong content-encoding and length may be a bug, removing
all the headers is not a fix.
> I am not submitting a patch yet since I'm not sure what the best fix is, but I guess
the best patch is to remove those two header lines and store the rest of the headers. If there
is no objection, I can submit a patch that does this. Otherwise, what would be a better fix?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message