CouchDB
  1. CouchDB
  2. COUCHDB-891

Allow ?keys=["a","b"] for GET to _view and _list

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0.1
    • Fix Version/s: 1.0.2
    • Component/s: HTTP Interface
    • Labels:
      None
    • Environment:

      -

    • Skill Level:
      Regular Contributors Level (Easy to Medium)

      Description

      The idea was already described back in 2008 when the POST

      {"keys":["key1","key2"]}

      API was introduced.

      http://mail-archives.apache.org/mod_mbox/couchdb-dev/200811.mbox/%3C4910D88A.8000809@kore-nordmann.de%3E

      I'm looking at the source right now, but can't figure out how to implement this at the moment, and I'd love this to be part of CouchDB proper.

        Activity

        Hide
        Sebastian Cohnen added a comment -

        The problem with GET is that the length of the request is limited by (browser) implementation - RFC 2616 [1] does not specify a limit to the URI length. I think it's a very bad behavior if GET with keys works for X keys, but no longer for X+1. I'm also not sure what to win by this change...

        [1] RFC 2616, 3.2.1 General Syntax:
        The HTTP protocol does not place any a priori limit on the length of
        a URI. Servers MUST be able to handle the URI of any resource they
        serve, and SHOULD be able to handle URIs of unbounded length if they
        provide GET-based forms that could generate such URIs. A server
        SHOULD return 414 (Request-URI Too Long) status if a URI is longer
        than the server can handle (see section 10.4.15).

        Note: Servers ought to be cautious about depending on URI lengths
        above 255 bytes, because some older client or proxy
        implementations might not properly support these lengths.

        Show
        Sebastian Cohnen added a comment - The problem with GET is that the length of the request is limited by (browser) implementation - RFC 2616 [1] does not specify a limit to the URI length. I think it's a very bad behavior if GET with keys works for X keys, but no longer for X+1. I'm also not sure what to win by this change... [1] RFC 2616, 3.2.1 General Syntax: The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
        Hide
        Michael Fellinger added a comment -

        If you don't know the size of the keys, you can use POST, I'm not advocating this as a replacement, but as an alternative.
        My typical usage is to lookup up to a handful of keys, of known size, that fit comfortably in any URI.

        I recently hit an issue while trying to implement a _list document for FreeSWITCH (FS) configuration, that is queried directly.
        Unfortunately, i cannot redirect or rewrite the request for a _list with keys via POST, and I cannot modify the way FS does its queries, so I had to put a middleware in front just to handle this query for me.
        With GET, it would be trivial to handle this case, I'd leave it to the developer to decide whether to use GET or POST.

        Show
        Michael Fellinger added a comment - If you don't know the size of the keys, you can use POST, I'm not advocating this as a replacement, but as an alternative. My typical usage is to lookup up to a handful of keys, of known size, that fit comfortably in any URI. I recently hit an issue while trying to implement a _list document for FreeSWITCH (FS) configuration, that is queried directly. Unfortunately, i cannot redirect or rewrite the request for a _list with keys via POST, and I cannot modify the way FS does its queries, so I had to put a middleware in front just to handle this query for me. With GET, it would be trivial to handle this case, I'd leave it to the developer to decide whether to use GET or POST.
        Hide
        Chris Anderson added a comment -

        I think this would also be a good intro patch for someone new to the codebase.

        Show
        Chris Anderson added a comment - I think this would also be a good intro patch for someone new to the codebase.
        Hide
        Jeff Zellner added a comment -

        I've implemented this functionality for view and list handlers.

        I added a couch_httpd:qs_json_value/3 function, since it was needed in two places for now. I guess it's not unfathomable that it would be useful elsewhere. I'm hilariously new to and stupid with git, so please let me know if this patch is up to snuff, as it's my first!

        Show
        Jeff Zellner added a comment - I've implemented this functionality for view and list handlers. I added a couch_httpd:qs_json_value/3 function, since it was needed in two places for now. I guess it's not unfathomable that it would be useful elsewhere. I'm hilariously new to and stupid with git, so please let me know if this patch is up to snuff, as it's my first!
        Hide
        Paul Joseph Davis added a comment -

        Looks like you forgot to add support for _all_docs. Other than that the patch looks great.

        Show
        Paul Joseph Davis added a comment - Looks like you forgot to add support for _all_docs. Other than that the patch looks great.
        Hide
        Jeff Zellner added a comment -

        Added to _all_docs handler, thanks for the catch

        Show
        Jeff Zellner added a comment - Added to _all_docs handler, thanks for the catch
        Hide
        Paul Joseph Davis added a comment -

        Instead of attaching two patches you should condense them into a single patch.

        You said your git-fu is still growing so the easiest way is to git diff between your branch and trunk. Once your git-fu grows, the usual method would be to interactively rebase your changes into a single commit. That sounds scarier than it is, and once you learn it you'll understand why git people can no longer use svn.

        Show
        Paul Joseph Davis added a comment - Instead of attaching two patches you should condense them into a single patch. You said your git-fu is still growing so the easiest way is to git diff between your branch and trunk. Once your git-fu grows, the usual method would be to interactively rebase your changes into a single commit. That sounds scarier than it is, and once you learn it you'll understand why git people can no longer use svn.
        Hide
        Jeff Zellner added a comment -

        Fixed up single patch attached – thanks for the help.

        Show
        Jeff Zellner added a comment - Fixed up single patch attached – thanks for the help.
        Hide
        Paul Joseph Davis added a comment -

        Just realized I forgot to tell you to add javascript tests. There's a place where the current keys POST is tested. adding similar tests near there would be sufficient.

        Show
        Paul Joseph Davis added a comment - Just realized I forgot to tell you to add javascript tests. There's a place where the current keys POST is tested. adding similar tests near there would be sufficient.
        Hide
        Robert Newson added a comment -

        What happened about the concern that this new function will work for short lists and then fail (with no remedy) for longer ones?

        Show
        Robert Newson added a comment - What happened about the concern that this new function will work for short lists and then fail (with no remedy) for longer ones?
        Hide
        Paul Joseph Davis added a comment -

        I think the remedy of longer lists is that you use POST. I think the concern is fine, but its not like we don't have the same concern for anything else that's user specifiable and appears in the URL. For instance, there's no length limit on document id's or attachment names which can hit the same URL length issue.

        Also, the method allows for cacheing when the POST method doesn't.

        Show
        Paul Joseph Davis added a comment - I think the remedy of longer lists is that you use POST. I think the concern is fine, but its not like we don't have the same concern for anything else that's user specifiable and appears in the URL. For instance, there's no length limit on document id's or attachment names which can hit the same URL length issue. Also, the method allows for cacheing when the POST method doesn't.
        Hide
        Jeff Zellner added a comment -

        Okay, now featuring lots of passing tests.

        Show
        Jeff Zellner added a comment - Okay, now featuring lots of passing tests.
        Hide
        Paul Joseph Davis added a comment -

        Does anyone not want this in trunk? I applied it and ran the tests. Everything is kosher from that point of view.

        Show
        Paul Joseph Davis added a comment - Does anyone not want this in trunk? I applied it and ran the tests. Everything is kosher from that point of view.
        Show
        Paul Joseph Davis added a comment - Applied. http://svn.apache.org/viewvc?revision=1033676&view=revision

          People

          • Assignee:
            Unassigned
            Reporter:
            Michael Fellinger
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development