_temp_view insists on Content-Type

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

It seems to be inconsistent that a POST to _temp_view only works if
Content-Type: application/json is provided, whereas in every other part of
the API I've exercised so far it's not needed (example below).

I see there is explicit code enforcing this, in
couch_httpd_view:handle_temp_view_req/2

Could someone explain what the reason is for this?

Thanks,

Brian.

$ curl -X POST -d '{"map":"function(doc) { emit(null, null) }"}'
http://127.0.0.1:5984/couchtiny-test/_temp_view
{"error":"incorrect_mime_type","reason":"application/x-www-form-urlencoded"}
$ curl -X POST -d '{"map":"function(doc) { emit(null, null) }"}' -H "Content-Type: application/json" http://127.0.0.1:5984/couchtiny-test/_temp_view
{"total_rows":3,"offset":0,"rows":[
{"id":"fred","key":null,"value":null},
{"id":"jim","key":null,"value":null},
{"id":"trunky","key":null,"value":null}
]}

Re: _temp_view insists on Content-Type

[Chris Anderson <jc...@apache.org>]

On Thu, Apr 2, 2009 at 12:20 PM, Paul Davis <pa...@gmail.com> wrote:
> My initial reaction would be to add checks to the rest of the API but
> I fear that it'd cause some pain for users of access mechanisms that
> either make adding headers difficult or things like curl where its
> just a pain.
>

We used to have more checks but we took them out because they were
annoying. We can take them out here as well, it's just a matter of
writing the patch.

> On Thu, Apr 2, 2009 at 3:12 PM, Brian Candler <B....@pobox.com> wrote:
>> It seems to be inconsistent that a POST to _temp_view only works if
>> Content-Type: application/json is provided, whereas in every other part of
>> the API I've exercised so far it's not needed (example below).
>>
>> I see there is explicit code enforcing this, in
>> couch_httpd_view:handle_temp_view_req/2
>>
>> Could someone explain what the reason is for this?
>>
>> Thanks,
>>
>> Brian.
>>
>> $ curl -X POST -d '{"map":"function(doc) { emit(null, null) }"}'
>> http://127.0.0.1:5984/couchtiny-test/_temp_view
>> {"error":"incorrect_mime_type","reason":"application/x-www-form-urlencoded"}
>> $ curl -X POST -d '{"map":"function(doc) { emit(null, null) }"}' -H "Content-Type: application/json" http://127.0.0.1:5984/couchtiny-test/_temp_view
>> {"total_rows":3,"offset":0,"rows":[
>> {"id":"fred","key":null,"value":null},
>> {"id":"jim","key":null,"value":null},
>> {"id":"trunky","key":null,"value":null}
>> ]}
>>
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Re: _temp_view insists on Content-Type

[Paul Davis <pa...@gmail.com>]

My initial reaction would be to add checks to the rest of the API but
I fear that it'd cause some pain for users of access mechanisms that
either make adding headers difficult or things like curl where its
just a pain.

On Thu, Apr 2, 2009 at 3:12 PM, Brian Candler <B....@pobox.com> wrote:
> It seems to be inconsistent that a POST to _temp_view only works if
> Content-Type: application/json is provided, whereas in every other part of
> the API I've exercised so far it's not needed (example below).
>
> I see there is explicit code enforcing this, in
> couch_httpd_view:handle_temp_view_req/2
>
> Could someone explain what the reason is for this?
>
> Thanks,
>
> Brian.
>
> $ curl -X POST -d '{"map":"function(doc) { emit(null, null) }"}'
> http://127.0.0.1:5984/couchtiny-test/_temp_view
> {"error":"incorrect_mime_type","reason":"application/x-www-form-urlencoded"}
> $ curl -X POST -d '{"map":"function(doc) { emit(null, null) }"}' -H "Content-Type: application/json" http://127.0.0.1:5984/couchtiny-test/_temp_view
> {"total_rows":3,"offset":0,"rows":[
> {"id":"fred","key":null,"value":null},
> {"id":"jim","key":null,"value":null},
> {"id":"trunky","key":null,"value":null}
> ]}
>