[
https://issues.apache.org/jira/browse/COUCHDB-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743064#action_12743064
]
Benoit Chesneau commented on COUCHDB-461:
-----------------------------------------
well according the spec :
"All HTTP/1.1 applications MUST be able to receive and decode the "chunked"
transfer-coding, and MUST ignore chunk-extension extensions they do not
understand. "
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
Also for the order chunk then content-length, according the spec :
Messages MUST NOT include both a Content-Length header field and a non-identity
transfer-coding. If the message does include a non- identity transfer-coding,
the Content-Length MUST be ignored.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
I think chunked encoding is still good for some purpose, it allows the client
to set buffer dynamically, and ignore bad chunks which could save some
bandwidth/time .
> attachments - handle correctly chunked encoding and Content-Length, send
> attachments unchunked
> ----------------------------------------------------------------------------------------------
>
> Key: COUCHDB-461
> URL: https://issues.apache.org/jira/browse/COUCHDB-461
> Project: CouchDB
> Issue Type: Bug
> Reporter: Benoit Chesneau
> Fix For: 0.10
>
> Attachments: attachments_get_length.diff,
> attachments_put_length.diff, chunked.diff, chunked2.diff
>
>
> This patch allow couchdb to send attachments unchunked, instead,
> Content-Length is fixed and content is streamed. It also fix attachments PUT
> by detecting first if encoding is chunked then test the length witch is the
> standard way to do it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
