[99s-extend] Accept header in POST request

[Loïc Hoguin]

Sure. It won't be called if not a GET or HEAD request so that's probably 
the best value you can return in your case.

On 02/03/2014 08:08 PM, Łukasz Biedrycki wrote:
> 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
> <mailto: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>
>         <mailto: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>
>         <mailto:Extend at lists.__ninenines.eu
>         <mailto:Extend at lists.ninenines.eu>>
>         https://lists.ninenines.eu/____listinfo/extend
>         <https://lists.ninenines.eu/__listinfo/extend>
>
>                  <https://lists.ninenines.eu/__listinfo/extend
>         <https://lists.ninenines.eu/listinfo/extend>>
>
>
>              --
>              Loïc Hoguin
>         http://ninenines.eu
>
>
>
>     --
>     Loïc Hoguin
>     http://ninenines.eu
>
>

-- 
Loïc Hoguin
http://ninenines.eu