[ 
https://issues.apache.org/jira/browse/COUCHDB-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick North updated COUCHDB-1953:
--------------------------------

    Attachment: tests1953.erl

To help with reviewing, I've attached some tests in the file tests1953.erl. The 
only code change is to replace couch_httpd:find_in_binary/2 so that is what the 
tests concentrate on. The file is standalone: just compile it and run 
tests1953:tests() and it should return a list of true atoms (it's a very simple 
test harness).

The tests check that finding a pattern in a binary finds the pattern when it 
should, does not find it when it should not, and gives the correct partial 
match when the binary ends with a prefix of the pattern (plus all sorts of 
variants with contained prefixes and the pattern occurring at different points 
in the binary). The file also contains cases where behaviour differs from the 
current implementation - in general they will be different when the pattern is 
not in the binary, but some prefix of the pattern occurs before the end of the 
binary - the existing code will match the prefix while the new code will not.

> Speed up parsing of multipart/related requests
> ----------------------------------------------
>
>                 Key: COUCHDB-1953
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1953
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: HTTP Interface
>            Reporter: Nick North
>         Attachments: tests1953.erl
>
>
> Parsing of multipart/related requests searches for the MIME boundary string 
> using the couch_httpd:find_in_binary/2 function, which can be made more 
> efficient.
> When the boundary string is not found in its entirety in the search data, the 
> function should then look to see if the data ends with a prefix of the 
> string, but it currently looks for any prefix of the string almost anywhere 
> in the search data.
> A pull request to fix this will be submitted shortly.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to