Re: [jira] Commented: (COUCHDB-235) Doesn't gracefully handle malformed URLs

[Michael McDaniel <co...@autosys.us>]

On Wed, Nov 11, 2009 at 05:03:39PM +0000, Roshan Kulkarni (JIRA) wrote:
> 
>     [ https://issues.apache.org/jira/browse/COUCHDB-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776515#action_12776515 ] 
> 
> Roshan Kulkarni commented on COUCHDB-235:
> -----------------------------------------
> 
> Noticed the same issue with CouchDB 0.11. I was trying to call a view from command line curl. The view used a composite key having a space in it. See example below:
> 
> curl -X GET "http://localhost:5984/mydatabase/_design/mydesign1/_view/myView?key=\[\"1234\",\"one two\"\]"
> 
> I get an "empty reply from server" every time. Thanks Brian for reporting this. This works perfectly well if the URL is hit from firefox.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 And the firefox URL shows an actual space and not %20  ?


 I'll posit that  \"one+two\"  or \"one%20two\"  works from curl. 
  

~M


> 
> 
> 
> > Doesn't gracefully handle malformed URLs
> > ----------------------------------------
> >
> >                 Key: COUCHDB-235
> >                 URL: https://issues.apache.org/jira/browse/COUCHDB-235
> >             Project: CouchDB
> >          Issue Type: Improvement
> >          Components: HTTP Interface
> >    Affects Versions: 0.9
> >         Environment: CentOS 5.2, Ubuntu Hardy
> > couchdb - Apache CouchDB 0.9.0a739811-incubating
> >            Reporter: Brian Candler
> >            Priority: Minor
> >
> > This one took me a while to track down, and Couchdb could have helped me more :-)
> > If you use curl to submit a request which includes a space, couchdb drops the connection on the floor: no response whatsoever, and nothing in logs. e.g.
> > $ curl 'http://localhost:5984/test_suite_db/_a_view/foo/bar?key="one two"'
> > curl: (52) Empty reply from server
> > When you check with tcpdump, it turns out that curl is not URL-encoding the space, but passing it straight through:
> > ...
> >         0x0030:  0e38 b57c 4745 5420 2f74 6573 745f 7375  .8.|GET./test_su
> >         0x0040:  6974 655f 6462 2f5f 615f 7669 6577 2f66  ite_db/_a_view/f
> >         0x0050:  6f6f 2f62 6172 3f6b 6579 3d22 6f6e 6520  oo/bar?key="one.
> >         0x0060:  7477 6f22 2048 5454 502f 312e 310d 0a55  two".HTTP/1.1..U
> >         0x0070:  7365 722d 4167 656e 743a 2063 7572 6c2f  ser-Agent:.curl/
> >         0x0080:  372e 3135 2e35 2028 6936 3836 2d72 6564  7.15.5.(i686-red
> >         0x0090:  6861 742d 6c69 6e75 782d 676e 7529 206c  hat-linux-gnu).l
> > ...
> > This happens with both versions of curl I tried (7.15.5 from CentOS 5.2, and 7.18.0 from Ubuntu Hardy)
> > This is arguably a bug in curl: it should either encode the space or reject the whole URL.
> > However, I wonder if couchdb could be a little more forgiving in this case, and at least return some sort of error to the client, like a 400 Bad Request.
> > For comparison: under the same circumstances, Apache (2.2.8) actually accepts and processes the request, just giving a 404 if the document isn't found.
> > The BNF in RFC 2616 says:
> >   Request-Line = Method SP Request-URI SP HTTP-Version CRLF
> > RFC 1738 says that space is unsafe, and unsafe characters MUST be encoded in URLs.  So Couchdb is within its rights to reject it - it would just be helpful if it could give an error.
> 
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
> 

-- 
Michael McDaniel
Portland, Oregon, USA
http://trip.autosys.us

Re: [jira] Commented: (COUCHDB-235) Doesn't gracefully handle malformed URLs

[Brian Candler <B....@pobox.com>]

On Wed, Nov 11, 2009 at 09:22:01AM -0800, Michael McDaniel wrote:
>  And the firefox URL shows an actual space and not %20  ?

Firefox shows a space, but sends %20 (as shown by couchdb logs or tcpdump)

>  I'll posit that  \"one+two\"  or \"one%20two\"  works from curl. 

It does. However the reported issue is that \"one two\" is handled in an
ungraceful or confusing way.