[99s-extend] Accept header in POST request

[Łukasz Biedrycki]

Ok,
it is more clear for me.

Last question I have is about content_types_provided function.

Is it safe to define it like this?

content_types_provided(R, S) ->
   ContentTypes = [{{<<"application">>, <<"json">>, '*'}, *undefined*}],
   {ContentTypes, Req, State}.

Callback in content_types_provided is useless for POST requests, as it
won’t be called.
Is it safe to use *undefined *atom, to have a source code clearer?




On Mon, Feb 3, 2014 at 7:37 PM, Loïc Hoguin <essen at ninenines.eu> wrote:

> If Accept is sent and is different than text/html, yes.
>
> This is how HTTP is defined. If the client says it speaks only
> content-type X but you can only reply with content-type Y, you error out
> early and stop processing the request. On the other hand if the client
> doesn't say what content-type it speaks then the server can choose
> whichever one it wants.
>
>
> On 02/03/2014 07:26 PM, Łukasz Biedrycki wrote:
>
>> My application sends both headers: “Content-type” and “Accept” header
>> using POST method.
>>
>> For POST rest handler do I have to specify both: content_types_accepted
>> and content_types_provided to manage this kind of request?
>>
>>
>> On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <essen at ninenines.eu
>> <mailto:essen at ninenines.eu>> wrote:
>>
>>     The content-type provided is relevant for any response, not just
>>     responses to GET requests. It defaults to text/html. If your client
>>     doesn't send that content-type, you have to define the callback.
>>
>>     I notice that the documentation is incorrect about the relevant
>>     methods for this callback, I will open a ticket to fix it soon.
>>
>>
>>     On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:
>>
>>         Hi,
>>         I have a rest handler that accepts POST and PUT requests with
>>         “application/json” content type.
>>
>>         I have content_types_accepted function defined as follows:
>>
>>         content_types_accepted(Req, State) ->
>>
>>
>>         {[{‘application/json', from_json}], Req, State}.
>>
>>
>>
>>         The problem I have is within a request that has two headers:
>>
>>         *Content-type*: application/json
>>         *Accept*: application/json
>>
>>         With this combination I receive *406*.
>>
>>
>>         You can repeat it with test:
>>
>>         http_SUITE.erl:
>>         1072 rest_postonly(Config) ->
>>         1073     Client = ?config(client, Config),
>>         1074     Headers = [
>>         1075         {<<"content-type">>, <<"text/plain">>},
>>         1076         {<<"accept">>, <<"text/plain">>}
>>         1077     ],
>>         1078     {ok, Client2} = cowboy_client:request(<<"POST"__>>,
>>
>>         1079         build_url("/postonly", Config), Headers, "12345",
>>         Client),
>>         1080     {ok, 204, _, _} = cowboy_client:response(__Client2).
>>
>>
>>         My solution to that was to add a content_types_provided function:
>>
>>
>>         content_types_provided(Req, State) ->
>>
>>
>>         ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}],
>>
>>
>>         {ContentTypes, Req, State}.
>>
>>
>>
>>         But it is useless as *to_json* callback registered is not called
>>         anyhow.
>>
>>         Adding *content_types_provided* function is a correct solution
>>         in this case?
>>
>>         Or I am missing something here?
>>         “Accept” header is not relevant only in case of GET requests?
>>
>>         Thank for help,
>>         Łukasz Biedrycki
>>
>>
>>         _________________________________________________
>>         Extend mailing list
>>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
>>         https://lists.ninenines.eu/__listinfo/extend
>>
>>         <https://lists.ninenines.eu/listinfo/extend>
>>
>>
>>     --
>>     Loïc Hoguin
>>     http://ninenines.eu
>>
>>
>>
> --
> Loïc Hoguin
> http://ninenines.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20140203/088e7e6a/attachment.html>