[
https://issues.apache.org/jira/browse/COUCHDB-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana updated COUCHDB-1174:
-----------------------------------
Attachment: couchdb-1174_2.patch
There's even another issue, besides replying before the parser is finished:
The data function does a socket recv call with 0 as the length - this means
"give me all the data in socket". I've now seen, very rarely, that with this
approach the multipart parser can steal some data of a subsequent request in
the connection, which is simply silently discard after.
The solution here is to use the multipart request's content-lentgh and keep
track of how much was already received before each data function call.
> Multipart parsing bug in new replicator
> ---------------------------------------
>
> Key: COUCHDB-1174
> URL: https://issues.apache.org/jira/browse/COUCHDB-1174
> Project: CouchDB
> Issue Type: Bug
> Affects Versions: 1.0.2, 1.1, 1.2
> Reporter: Robert Newson
> Priority: Blocker
> Fix For: 1.0.3, 1.1, 1.2
>
> Attachments: COUCHDB-1174.sh, couchdb-1174.patch, couchdb-1174_2.patch
>
>
> It seems the new multipart savvy replicator has a bug. At high load, the
> receiving node sees the following as the method of a new http request;
> "--17481297448f5a282cc919203957ebd9--POST"
> instead of just "POST". The first bit looks like a multipart boundary value
> to me.
> I'll attach a script that reproduces the error now.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
