Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Tue, 17 Jul 2012 14:15:35 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <1087592776.64051.1342534535179.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1987133318.59121.1342461274950.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (HDFS-3671) ByteRangeInputStream shouldn't
 require the content length header be present
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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