CouchDB
  1. CouchDB
  2. COUCHDB-348

/ should redirect to a human readable page when accessed from a browser

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: HTTP Interface
    • Labels:
      None
    • Skill Level:
      New Contributors Level (Easy)

      Description

      As more people are adopting CouchDB, the number of questions along the lines of "All I see is

      {"couchdb":"Welcome","version":"0.10.0a773399"}

      , what now?"

      If this page redirected to /_utils/ (or maybe something more user-focussed) when the accept headers included html, we could make the first-time user experience more palatable.

      There's some code in COUCHDB-234 that might be helpful here.

      1. encs.erl
        5 kB
        Filipe Manana
      2. COUCHDB_348_03.patch
        5 kB
        Matthew Hooker
      3. COUCHDB_348_02.patch
        1 kB
        Matthew Hooker
      4. COUCHDB_348_01.patch
        1 kB
        Matthew Hooker

        Issue Links

          Activity

          Hide
          Benjamin Young added a comment - - edited

          Yeah, let's avoid the prefix conversation. If it must be done, it should happen and be discussed elsewhere...so we don't derail this antique bug getting fixed.

          Jan Lehnardt, I very much like the approach you've described. I do think it's feasible to at least detect the big 3 browsers (Firefox, WebKit collective, and IE) and route them accordingly--untold numbers of web servers do this successfully...certainly we can find a way.

          Another orthogonal discussion would be the use of something like HAL (Hypermedia Application Language) for defining things like this link in the JSON we return...but that's a separate can of worms that should stay separate.

          +1 on adding a link under vendor for now, and routing / to /_utils (or wherever based on a config setting...ideally) following that.

          Thanks, Jan Lehnardt

          Show
          Benjamin Young added a comment - - edited Yeah, let's avoid the prefix conversation. If it must be done, it should happen and be discussed elsewhere...so we don't derail this antique bug getting fixed. Jan Lehnardt , I very much like the approach you've described. I do think it's feasible to at least detect the big 3 browsers (Firefox, WebKit collective, and IE) and route them accordingly--untold numbers of web servers do this successfully...certainly we can find a way. Another orthogonal discussion would be the use of something like HAL (Hypermedia Application Language) for defining things like this link in the JSON we return...but that's a separate can of worms that should stay separate. +1 on adding a link under vendor for now, and routing / to /_utils (or wherever based on a config setting...ideally) following that. Thanks, Jan Lehnardt
          Hide
          Jan Lehnardt added a comment -

          I’d be against adding /couchdb as a required prefix, let alone the massive BC breakage and the losing of a really nice API that we worked hard to get right.

          Show
          Jan Lehnardt added a comment - I’d be against adding /couchdb as a required prefix, let alone the massive BC breakage and the losing of a really nice API that we worked hard to get right.
          Hide
          Benoit Chesneau added a comment -

          What about

          • / -> Json : api version , link to other resources (to allow the discovery)
          • /couchdb/ {...our api...}
          • /ui -> ui (or admin whatever) a

          Then we make sure to not pollute the API .

          Show
          Benoit Chesneau added a comment - What about / -> Json : api version , link to other resources (to allow the discovery) /couchdb/ {...our api...} /ui -> ui (or admin whatever) a Then we make sure to not pollute the API .
          Hide
          Jan Lehnardt added a comment -

          I agree on the first citizen bit, but there might be a way to make HTML a prominent second citizen

          Good bikeshed, I just wanted to explain the idea. I don’t care what the key name is

          Show
          Jan Lehnardt added a comment - I agree on the first citizen bit, but there might be a way to make HTML a prominent second citizen Good bikeshed, I just wanted to explain the idea. I don’t care what the key name is
          Hide
          Benoit Chesneau added a comment -

          imo JSON should be the first citizen of couchdb. At least on this resource.

          +1 for the second idea. Adding here other urls describing the resources would be also interesting, so a client could discover them.

          small bikeshedding , I would replace admin by ui there

          Show
          Benoit Chesneau added a comment - imo JSON should be the first citizen of couchdb. At least on this resource. +1 for the second idea. Adding here other urls describing the resources would be also interesting, so a client could discover them. small bikeshedding , I would replace admin by ui there
          Hide
          Jan Lehnardt added a comment -

          The way we’d do this is only show HTML if we can be reasonably certain we see a browser. That could be based on a number of headers we know only browsers send in that combination. If we can’t be sure, we send JSON, as usual. In addition we could store a cookie in the browser to mark this.

          Alternatively, we could send a link to /_utils in the welcome JSON:

          {"couchdb":"Welcome","uuid":"0189308e0394cfdcf495074d7dec7cd7","version":"1.5.0","vendor":{"version":"1.5.0","name":"The Apache Software Foundation", "admin":"http://127.0..0.1:5984/_utils/"}}

          (inside vendor because e.g. Cloudant might have a different URL)

          Show
          Jan Lehnardt added a comment - The way we’d do this is only show HTML if we can be reasonably certain we see a browser. That could be based on a number of headers we know only browsers send in that combination. If we can’t be sure, we send JSON, as usual. In addition we could store a cookie in the browser to mark this. Alternatively, we could send a link to /_utils in the welcome JSON: {"couchdb":"Welcome","uuid":"0189308e0394cfdcf495074d7dec7cd7","version":"1.5.0","vendor":{"version":"1.5.0","name":"The Apache Software Foundation", "admin":"http://127.0..0.1:5984/_utils/"}} (inside vendor because e.g. Cloudant might have a different URL)
          Hide
          Benjamin Young added a comment -

          Meh. Plugin time.

          Show
          Benjamin Young added a comment - Meh. Plugin time.
          Hide
          Alexander Shorin added a comment -

          cUrl is not only cli http client. There are others good and popular tools like httpie, wget and might be more around. Supporting such exception list looks very doubtful.

          Show
          Alexander Shorin added a comment - cUrl is not only cli http client. There are others good and popular tools like httpie , wget and might be more around. Supporting such exception list looks very doubtful.
          Hide
          Robert Newson added a comment -

          "It beats not doing it."

          I agree with Joan and others that this ship has sailed.

          Show
          Robert Newson added a comment - "It beats not doing it." I agree with Joan and others that this ship has sailed.
          Hide
          Benjamin Young added a comment -

          So clients can be changed far more easily than browser. Additionally, we can do some User-Agent string sniffing if it comes to that.

          curl sends Accept: / and User-Agent: curl/7.30.0 fwiw.

          Browser sniffing is an old (dark) art, and seems it wouldn't be terrible to tackle that and default to the application/json when we can't figure it out.

          Certainly a note about the change with a minor (or major) point release along with contacting client authors directly and even doing a bit of testing/documenting/pull-requesting would be needed for the smoothest transition.

          It beats not doing it.

          Show
          Benjamin Young added a comment - So clients can be changed far more easily than browser. Additionally, we can do some User-Agent string sniffing if it comes to that. curl sends Accept: / and User-Agent: curl/7.30.0 fwiw. Browser sniffing is an old (dark) art, and seems it wouldn't be terrible to tackle that and default to the application/json when we can't figure it out. Certainly a note about the change with a minor (or major) point release along with contacting client authors directly and even doing a bit of testing/documenting/pull-requesting would be needed for the smoothest transition. It beats not doing it.
          Hide
          Joan Touzet added a comment -

          Maybe we "had this backwards" from the start, but it's too late to change it now.

          We know for a fact that your suggestion breaks some programmatic clients hitting /. Earlier this year, Robert Newson and Simon Metson I believe had a list of specific clients that broke on this, and it's a non-insignificant percentage of the world. It would also break naive curl samples and how-tos that have been around for years - it's way, way more than just Futon and Fauxton that hit / !

          Show
          Joan Touzet added a comment - Maybe we "had this backwards" from the start, but it's too late to change it now. We know for a fact that your suggestion breaks some programmatic clients hitting /. Earlier this year, Robert Newson and Simon Metson I believe had a list of specific clients that broke on this, and it's a non-insignificant percentage of the world. It would also break naive curl samples and how-tos that have been around for years - it's way, way more than just Futon and Fauxton that hit / !
          Hide
          Benjamin Young added a comment -

          What if we had this backwards? What if / defaulted to text/html unless the client (aka, CouchDB libraries, HTTP libs, etc) explicitly requested otherwise?

          Browsers, then get Futon/Fauxton handed to them. Clients that hit the / resource (mostly Futon & Fauxton, I'd recon), then be sure they're asking for application/json when hitting that URL. They should be anyway if that's what they want.

          That seems like a lighter, faster fix that won't break (m)any things. One hopes...

          Show
          Benjamin Young added a comment - What if we had this backwards? What if / defaulted to text/html unless the client (aka, CouchDB libraries, HTTP libs, etc) explicitly requested otherwise? Browsers, then get Futon/Fauxton handed to them. Clients that hit the / resource (mostly Futon & Fauxton, I'd recon), then be sure they're asking for application/json when hitting that URL. They should be anyway if that's what they want. That seems like a lighter, faster fix that won't break (m)any things. One hopes...
          Hide
          Dave Cottlehuber added a comment -

          Intractable.

          Show
          Dave Cottlehuber added a comment - Intractable.
          Hide
          Dave Cottlehuber added a comment -

          +1, Close it. This has been open for 5 years and the general agreement is that there's no straightforward solution until browsers are fixed.

          Show
          Dave Cottlehuber added a comment - +1, Close it. This has been open for 5 years and the general agreement is that there's no straightforward solution until browsers are fixed.
          Hide
          Robert Newson added a comment -

          I'm +1 for closing this given the fairly intractable detection problem but at least bumping this past 1.3.x.

          Show
          Robert Newson added a comment - I'm +1 for closing this given the fairly intractable detection problem but at least bumping this past 1.3.x.
          Hide
          Joan Touzet added a comment - - edited

          Assigning to a committer...

          Show
          Joan Touzet added a comment - - edited Assigning to a committer...
          Hide
          Joan Touzet added a comment -

          We spent a week on this at Cloudant, trying to put a nice dashboard at the top-level, and found far too many broken user-agents and programmatic libraries that expect JSON (pycurl is a good example, but IE as well where it accepts /) where sending back a friendly top-level page vs. JSON is a huge issue.

          I propose we close this as WONTFIX and consider alternative approaches in COUCHDB-472, such as /index.html redirecting to a nice human-readable page.

          Show
          Joan Touzet added a comment - We spent a week on this at Cloudant, trying to put a nice dashboard at the top-level, and found far too many broken user-agents and programmatic libraries that expect JSON (pycurl is a good example, but IE as well where it accepts / ) where sending back a friendly top-level page vs. JSON is a huge issue. I propose we close this as WONTFIX and consider alternative approaches in COUCHDB-472 , such as /index.html redirecting to a nice human-readable page.
          Hide
          Jan Lehnardt added a comment -

          Bump to 1.3.x

          Show
          Jan Lehnardt added a comment - Bump to 1.3.x
          Hide
          Philippe Koenig added a comment -

          @All
          I think this discussion goes in the wrong way.
          I'm using extensively couch and THE missing point (at this level) is the ability to SET the desired home url for the server AND for each DB
          The adding of those two parameters will be the solution for many problems that i solve with a reverse proxy ans some rewriting rules
          Vhosts and _rewrites are not enough in many case

          See what happens

          Show
          Philippe Koenig added a comment - @All I think this discussion goes in the wrong way. I'm using extensively couch and THE missing point (at this level) is the ability to SET the desired home url for the server AND for each DB The adding of those two parameters will be the solution for many problems that i solve with a reverse proxy ans some rewriting rules Vhosts and _rewrites are not enough in many case See what happens
          Hide
          Matt Goodall added a comment -

          A good example of IE's accept header is:

          Accept: image/jpeg, application/x-ms-application, image/gif,
          application/xaml+xml, image/pjpeg, application/x-ms-xbap,
          application/x-shockwave-flash, application/msword, /

          I took that from http://www.newmediacampaigns.com/page/browser-rest-http-accept-headers but there are plenty of other examples if you search for "internet explorer accept header".

          @paul, yes the server can decide what to return when / is the best match. Some servers implement a server-side quality, e.g. q=0.9, to decide what representation to return.

          And, even though I brought this up, I'm actually with Noah on "If it doesn't work for all clients, it doesn't work."

          Show
          Matt Goodall added a comment - A good example of IE's accept header is: Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/msword, / I took that from http://www.newmediacampaigns.com/page/browser-rest-http-accept-headers but there are plenty of other examples if you search for "internet explorer accept header". @paul, yes the server can decide what to return when / is the best match. Some servers implement a server-side quality, e.g. q=0.9, to decide what representation to return. And, even though I brought this up, I'm actually with Noah on "If it doesn't work for all clients, it doesn't work."
          Hide
          Filipe Manana added a comment -

          Matthew, regarding the of parsing Q values, I did it for a patch to 583. It was done for parsing the "Accept-Encoding" header, but it should be reusable for other Q values lists. I didn't find it in Mochiweb also I agree with yout, it's boring to do such a parsing function.

          I add it here in a separate file with test functions. The main function is build_enc_lists/1, which builds 2 lists, one for Q values > 0, and the other with Q values == 0. It ignores white spaces all over and it's case insensitive (as rfc 2626 says):

          test_build_lists() ->

          {[], []}

          = build_enc_lists(""),

          {[], [identity]} = build_enc_lists("identity;q=0"),
          {[], [identity]}

          = build_enc_lists("identity ;q=0"),

          {[], [identity]} = build_enc_lists(" identity; q =0 "),
          {[], [identity]}

          = build_enc_lists("identity ; q = 0"),

          {[], [identity]}

          = build_enc_lists("identity ; q= 0.0"),

          {[gzip, deflate], [identity]} = build_enc_lists("gzip,deflate,identity;q=0.0"),
          {[deflate, gzip], [identity]} = build_enc_lists("deflate,gzip,identity;q=0.0"),
          {[gzip, deflate, gzip], [identity]} = build_enc_lists("gzip,deflate,gzip,identity;q=0"),
          {[gzip, deflate], [identity]}

          = build_enc_lists("gzip, deflate , identity; q=0.0"),

          {[gzip, deflate], [identity]}

          = build_enc_lists("gzip; q=1, deflate;q=1.0, identity;q=0.0"),

          {[deflate, gzip], [identity]} = build_enc_lists("gzip; q=0.5, deflate;q=1.0, identity;q=0"),
          {[deflate, gzip], [identity]}

          = build_enc_lists("gzip; q=0.5, deflate , identity;q=0.0"),

          {[deflate, gzip], [identity]}

          = build_enc_lists("gzip; q=0.5, deflate;q=0.8, identity;q=0.0"),

          {[deflate, identity, gzip], []}

          = build_enc_lists("gzip; q=0.5,deflate,identity"),

          {[deflate, identity, identity, gzip], []}

          = build_enc_lists("gzip; q=0.5,deflate,identity, identity "),
          ok.

          cheers

          Show
          Filipe Manana added a comment - Matthew, regarding the of parsing Q values, I did it for a patch to 583. It was done for parsing the "Accept-Encoding" header, but it should be reusable for other Q values lists. I didn't find it in Mochiweb also I agree with yout, it's boring to do such a parsing function. I add it here in a separate file with test functions. The main function is build_enc_lists/1, which builds 2 lists, one for Q values > 0, and the other with Q values == 0. It ignores white spaces all over and it's case insensitive (as rfc 2626 says): test_build_lists() -> {[], []} = build_enc_lists(""), {[], [identity]} = build_enc_lists("identity;q=0"), {[], [identity]} = build_enc_lists("identity ;q=0"), {[], [identity]} = build_enc_lists(" identity; q =0 "), {[], [identity]} = build_enc_lists("identity ; q = 0"), {[], [identity]} = build_enc_lists("identity ; q= 0.0"), {[gzip, deflate], [identity]} = build_enc_lists("gzip,deflate,identity;q=0.0"), {[deflate, gzip], [identity]} = build_enc_lists("deflate,gzip,identity;q=0.0"), {[gzip, deflate, gzip], [identity]} = build_enc_lists("gzip,deflate,gzip,identity;q=0"), {[gzip, deflate], [identity]} = build_enc_lists("gzip, deflate , identity; q=0.0"), {[gzip, deflate], [identity]} = build_enc_lists("gzip; q=1, deflate;q=1.0, identity;q=0.0"), {[deflate, gzip], [identity]} = build_enc_lists("gzip; q=0.5, deflate;q=1.0, identity;q=0"), {[deflate, gzip], [identity]} = build_enc_lists("gzip; q=0.5, deflate , identity;q=0.0"), {[deflate, gzip], [identity]} = build_enc_lists("gzip; q=0.5, deflate;q=0.8, identity;q=0.0"), {[deflate, identity, gzip], []} = build_enc_lists("gzip; q=0.5,deflate,identity"), {[deflate, identity, identity, gzip], []} = build_enc_lists("gzip; q=0.5,deflate,identity, identity "), ok. cheers
          Hide
          Matthew Hooker added a comment -

          @benoitc Matt mentions that it might not work with IE, but I haven't checked. As Dirkjan points out, though, it should probably properly parse the Accept header.

          Show
          Matthew Hooker added a comment - @benoitc Matt mentions that it might not work with IE, but I haven't checked. As Dirkjan points out, though, it should probably properly parse the Accept header.
          Hide
          Benoit Chesneau added a comment -

          @ matthew I don't see why it shouldn't works with Interet Explorer here (speaking of my patch). Does ie rewrite the Accept header ?

          Show
          Benoit Chesneau added a comment - @ matthew I don't see why it shouldn't works with Interet Explorer here (speaking of my patch). Does ie rewrite the Accept header ?
          Hide
          Matthew Hooker added a comment -

          From the comments, it seems like a mix of the Accept detection and the human readable "Welcome" page in COUCHDB-472 is preferred. Attached is a patch which does just that.

          @paul I didn't see anything in Mochiweb that might deal with Accept headers or mime types. The code is under the MIT license.

          Show
          Matthew Hooker added a comment - From the comments, it seems like a mix of the Accept detection and the human readable "Welcome" page in COUCHDB-472 is preferred. Attached is a patch which does just that. @paul I didn't see anything in Mochiweb that might deal with Accept headers or mime types. The code is under the MIT license.
          Hide
          Noah Slater added a comment -

          Also, you missed the slippers.

          Show
          Noah Slater added a comment - Also, you missed the slippers.
          Hide
          Noah Slater added a comment -

          I would be happy with that screenshot being implemented.

          A link to Futon in both JSON and HTML would be good too.

          As for conneg, just sniff for anything with HTML.

          If it doesn't work for all clients, it doesn't work.

          Show
          Noah Slater added a comment - I would be happy with that screenshot being implemented. A link to Futon in both JSON and HTML would be good too. As for conneg, just sniff for anything with HTML. If it doesn't work for all clients, it doesn't work.
          Hide
          Paul Joseph Davis added a comment -

          @matt - So I'm unsuprised to learn that IE screws the pooch as per usual. But technically if they end up preferring / then if memory serves the server can choose. And I don't know why that choice couldn't be based on what exists in the User-Agent string if it exists.

          Show
          Paul Joseph Davis added a comment - @matt - So I'm unsuprised to learn that IE screws the pooch as per usual. But technically if they end up preferring / then if memory serves the server can choose. And I don't know why that choice couldn't be based on what exists in the User-Agent string if it exists.
          Hide
          Paul Joseph Davis added a comment -

          @matthew That mimeparse library is busted. media type parameters can be quoted which breaks the call to string:tokens("="). Though, that's not too crazy. Even WebOb is broken. Just saying is all. As to including it, you might double check if mochiweb already has something. If not, then as long as the license is kosher we'll put it in somewhere.

          @nslater Perhaps if someone had suggested redirecting to Futon based on Accept header you'd be in the right ballpark. As it so happens, we're discussing returning an alternate representation of the root resource with something that is human readable based on the accept headers. For instance, the general idea is to replace:

          {"couchdb":"Welcome","version":"0.11.0b890185"}

          with something like this:

          https://issues.apache.org/jira/secure/attachment/12416873/screenshot.png

          I could see adding a couple user friendly links to couchdb.apache.org, wiki.apache.org/couchdb and Futon. But the resource is still they same old "Hey buddy, glad you could make it, lemme get you a nice frosty cold glass of lemonade while you relax right here on this comfy couch."

          Cheerio!

          Show
          Paul Joseph Davis added a comment - @matthew That mimeparse library is busted. media type parameters can be quoted which breaks the call to string:tokens("="). Though, that's not too crazy. Even WebOb is broken. Just saying is all. As to including it, you might double check if mochiweb already has something. If not, then as long as the license is kosher we'll put it in somewhere. @nslater Perhaps if someone had suggested redirecting to Futon based on Accept header you'd be in the right ballpark. As it so happens, we're discussing returning an alternate representation of the root resource with something that is human readable based on the accept headers. For instance, the general idea is to replace: {"couchdb":"Welcome","version":"0.11.0b890185"} with something like this: https://issues.apache.org/jira/secure/attachment/12416873/screenshot.png I could see adding a couple user friendly links to couchdb.apache.org, wiki.apache.org/couchdb and Futon. But the resource is still they same old "Hey buddy, glad you could make it, lemme get you a nice frosty cold glass of lemonade while you relax right here on this comfy couch." Cheerio!
          Hide
          Noah Slater added a comment -

          This would be an abuse of HTTP semantics. Representations (i.e. the different media types) are meant to represent the same conceptual resource. Switching in Futon based on the Accept header would be a gross abuse of content negotiation, as Futon is not the HTML representation of any resource which also has the root CouchDB JSON response as another representation. The only two options we have for this ticket is to close it as WONTFIX, or to replace the root resource with Futon - that is, to make Futon live at the root of CouchDB.

          Show
          Noah Slater added a comment - This would be an abuse of HTTP semantics. Representations (i.e. the different media types) are meant to represent the same conceptual resource. Switching in Futon based on the Accept header would be a gross abuse of content negotiation, as Futon is not the HTML representation of any resource which also has the root CouchDB JSON response as another representation. The only two options we have for this ticket is to close it as WONTFIX, or to replace the root resource with Futon - that is, to make Futon live at the root of CouchDB.
          Hide
          Matt Goodall added a comment -

          I don't disagree with this at all - an HTML version of the couchdb root resource would make sense. However, some browsers (yes, Internet Explorer) don't always send text/html in the Accept header. So, sadly, it's not actually true that all browser prefer HTML to JSON. IE sends an insane Accept header and the best match ends up being "/" which means it may be up to the server to prioritise text/html over application/json.

          Show
          Matt Goodall added a comment - I don't disagree with this at all - an HTML version of the couchdb root resource would make sense. However, some browsers (yes, Internet Explorer) don't always send text/html in the Accept header. So, sadly, it's not actually true that all browser prefer HTML to JSON. IE sends an insane Accept header and the best match ends up being " / " which means it may be up to the server to prioritise text/html over application/json.
          Hide
          Benoit Chesneau added a comment -

          i posted a patch that display a "human" page and still send the message on accept header :

          https://issues.apache.org/jira/browse/COUCHDB-472

          Show
          Benoit Chesneau added a comment - i posted a patch that display a "human" page and still send the message on accept header : https://issues.apache.org/jira/browse/COUCHDB-472
          Hide
          Matthew Hooker added a comment - - edited

          properly parsing qvalues is actually kind of tricky. I probably would have messed up the implementation, but luckily there's a great library that does just that, hosted over at http://code.google.com/p/mimeparse/

          Attached also is the patch that uses that to correctly resolve this issue.

          The question now is, can I include that library in couch? If so, how? I can see it being quite useful for other things (e.g. COUCHDB-234).

          Thanks,

          Show
          Matthew Hooker added a comment - - edited properly parsing qvalues is actually kind of tricky. I probably would have messed up the implementation, but luckily there's a great library that does just that, hosted over at http://code.google.com/p/mimeparse/ Attached also is the patch that uses that to correctly resolve this issue. The question now is, can I include that library in couch? If so, how? I can see it being quite useful for other things (e.g. COUCHDB-234 ). Thanks,
          Hide
          Dirkjan Ochtman added a comment -

          It should probably parse the qvalues and try to only redirect if text/html (or maybe application/xhtml+xml?) gets higher priority than application/json.

          Show
          Dirkjan Ochtman added a comment - It should probably parse the qvalues and try to only redirect if text/html (or maybe application/xhtml+xml?) gets higher priority than application/json.
          Hide
          Matthew Hooker added a comment -

          I think this patch does what Chris described. I've tested it in firefox and curl, and I get the expected results.

          Not being super expert at either the CouchDB codebase or Erlang, I think this is sort of a naive approach, and would appreciate some feedback.

          It merely checks if the client is sending 'text/html' as part of the Accept header, and like COUCHDB-234, it doesn't respect qvalues, so if the client can do both html and json, it will get html.

          Thanks.

          Show
          Matthew Hooker added a comment - I think this patch does what Chris described. I've tested it in firefox and curl, and I get the expected results. Not being super expert at either the CouchDB codebase or Erlang, I think this is sort of a naive approach, and would appreciate some feedback. It merely checks if the client is sending 'text/html' as part of the Accept header, and like COUCHDB-234 , it doesn't respect qvalues, so if the client can do both html and json, it will get html. Thanks.
          Hide
          Adam Kocoloski added a comment -

          0.10.0 is out the door, adjusting FixFor on all remaining unresolved issues to 0.11 by default

          Show
          Adam Kocoloski added a comment - 0.10.0 is out the door, adjusting FixFor on all remaining unresolved issues to 0.11 by default
          Hide
          Chris Anderson added a comment -

          The check would be relatively straightforward, web-sane, and friendly to API clients. No browser-sniffing required.

          If the client sends an HTTP Accept header that prefers HTML to JSON (as browsers do), then we'd send HTML, otherwise we'd send JSON.

          Show
          Chris Anderson added a comment - The check would be relatively straightforward, web-sane, and friendly to API clients. No browser-sniffing required. If the client sends an HTTP Accept header that prefers HTML to JSON (as browsers do), then we'd send HTML, otherwise we'd send JSON.
          Hide
          Simon Thulbourn added a comment -

          I disagree, this should remain as it is. It allows for people writing API classes to perform a check to see if it's successful. Besides, how does it know what a browser is without parts of the user agent string to be checked every time something visits the page?

          Show
          Simon Thulbourn added a comment - I disagree, this should remain as it is. It allows for people writing API classes to perform a check to see if it's successful. Besides, how does it know what a browser is without parts of the user agent string to be checked every time something visits the page?

            People

            • Assignee:
              Robert Newson
              Reporter:
              Chris Anderson
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development