[
https://issues.apache.org/jira/browse/HDFS-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416233#comment-13416233
]
Daryn Sharp commented on HDFS-3671:
-----------------------------------
Since any fix is a hacky workaround for very old hadoop clusters that violate
the http rfc (see below), should we only increase the read timeout if a
content-length is missing? Or as I suggested before, use a file stat (or
simple HEAD request) if the content-length is missing? The latter will prevent
a minimum 200s tail on the transfers.
(An http server is required to close the connection when a transfer lacks a
content-length is complete in order to avoid this ambiguity on the client side.
However it's strongly advised not to leave out the header since the client
doesn't know if it only received a partial download, hence my suggestion to
fallback to size from a file stat.)
> ByteRangeInputStream shouldn't require the content length header be present
> ---------------------------------------------------------------------------
>
> Key: HDFS-3671
> URL: https://issues.apache.org/jira/browse/HDFS-3671
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha
> Reporter: Eli Collins
> Priority: Blocker
>
> Per HDFS-3318 the content length header check breaks distcp compatibility
> with previous releases (0.20.2 and earlier, and 0.21). Like branch-1 this
> check should be lenient.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
