<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE> [99s-extend] Accept header in POST request
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:extend%40lists.ninenines.eu?Subject=Re%3A%20%5B99s-extend%5D%20Accept%20header%20in%20POST%20request&In-Reply-To=%3CCAKfrUsiHdRRzsBJ_Ns%2Bsw2BdcwbB9dKbx-m6UUL%2BhRj%3D%3DwXY%3DA%40mail.gmail.com%3E">
<META NAME="robots" CONTENT="index,nofollow">
<style type="text/css">
pre {
white-space: pre-wrap; /* css-2.1, curent FF, Opera, Safari */
}
</style>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="000327.html">
<LINK REL="Next" HREF="000329.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[99s-extend] Accept header in POST request</H1>
<B>Łukasz Biedrycki</B>
<A HREF="mailto:extend%40lists.ninenines.eu?Subject=Re%3A%20%5B99s-extend%5D%20Accept%20header%20in%20POST%20request&In-Reply-To=%3CCAKfrUsiHdRRzsBJ_Ns%2Bsw2BdcwbB9dKbx-m6UUL%2BhRj%3D%3DwXY%3DA%40mail.gmail.com%3E"
TITLE="[99s-extend] Accept header in POST request">lukasz.biedrycki at gmail.com
</A><BR>
<I>Mon Feb 3 20:08:12 CET 2014</I>
<P><UL>
<LI>Previous message: <A HREF="000327.html">[99s-extend] Accept header in POST request
</A></li>
<LI>Next message: <A HREF="000329.html">[99s-extend] Accept header in POST request
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#328">[ date ]</a>
<a href="thread.html#328">[ thread ]</a>
<a href="subject.html#328">[ subject ]</a>
<a href="author.html#328">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>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 <<A HREF="https://lists.ninenines.eu/listinfo/extend">essen at ninenines.eu</A>> wrote:
><i> If Accept is sent and is different than text/html, yes.
</I>><i>
</I>><i> This is how HTTP is defined. If the client says it speaks only
</I>><i> content-type X but you can only reply with content-type Y, you error out
</I>><i> early and stop processing the request. On the other hand if the client
</I>><i> doesn't say what content-type it speaks then the server can choose
</I>><i> whichever one it wants.
</I>><i>
</I>><i>
</I>><i> On 02/03/2014 07:26 PM, Łukasz Biedrycki wrote:
</I>><i>
</I>>><i> My application sends both headers: “Content-type” and “Accept” header
</I>>><i> using POST method.
</I>>><i>
</I>>><i> For POST rest handler do I have to specify both: content_types_accepted
</I>>><i> and content_types_provided to manage this kind of request?
</I>>><i>
</I>>><i>
</I>>><i> On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <<A HREF="https://lists.ninenines.eu/listinfo/extend">essen at ninenines.eu</A>
</I>>><i> <mailto:<A HREF="https://lists.ninenines.eu/listinfo/extend">essen at ninenines.eu</A>>> wrote:
</I>>><i>
</I>>><i> The content-type provided is relevant for any response, not just
</I>>><i> responses to GET requests. It defaults to text/html. If your client
</I>>><i> doesn't send that content-type, you have to define the callback.
</I>>><i>
</I>>><i> I notice that the documentation is incorrect about the relevant
</I>>><i> methods for this callback, I will open a ticket to fix it soon.
</I>>><i>
</I>>><i>
</I>>><i> On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:
</I>>><i>
</I>>><i> Hi,
</I>>><i> I have a rest handler that accepts POST and PUT requests with
</I>>><i> “application/json” content type.
</I>>><i>
</I>>><i> I have content_types_accepted function defined as follows:
</I>>><i>
</I>>><i> content_types_accepted(Req, State) ->
</I>>><i>
</I>>><i>
</I>>><i> {[{‘application/json', from_json}], Req, State}.
</I>>><i>
</I>>><i>
</I>>><i>
</I>>><i> The problem I have is within a request that has two headers:
</I>>><i>
</I>>><i> *Content-type*: application/json
</I>>><i> *Accept*: application/json
</I>>><i>
</I>>><i> With this combination I receive *406*.
</I>>><i>
</I>>><i>
</I>>><i> You can repeat it with test:
</I>>><i>
</I>>><i> http_SUITE.erl:
</I>>><i> 1072 rest_postonly(Config) ->
</I>>><i> 1073 Client = ?config(client, Config),
</I>>><i> 1074 Headers = [
</I>>><i> 1075 {<<"content-type">>, <<"text/plain">>},
</I>>><i> 1076 {<<"accept">>, <<"text/plain">>}
</I>>><i> 1077 ],
</I>>><i> 1078 {ok, Client2} = cowboy_client:request(<<"POST"__>>,
</I>>><i>
</I>>><i> 1079 build_url("/postonly", Config), Headers, "12345",
</I>>><i> Client),
</I>>><i> 1080 {ok, 204, _, _} = cowboy_client:response(__Client2).
</I>>><i>
</I>>><i>
</I>>><i> My solution to that was to add a content_types_provided function:
</I>>><i>
</I>>><i>
</I>>><i> content_types_provided(Req, State) ->
</I>>><i>
</I>>><i>
</I>>><i> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}],
</I>>><i>
</I>>><i>
</I>>><i> {ContentTypes, Req, State}.
</I>>><i>
</I>>><i>
</I>>><i>
</I>>><i> But it is useless as *to_json* callback registered is not called
</I>>><i> anyhow.
</I>>><i>
</I>>><i> Adding *content_types_provided* function is a correct solution
</I>>><i> in this case?
</I>>><i>
</I>>><i> Or I am missing something here?
</I>>><i> “Accept” header is not relevant only in case of GET requests?
</I>>><i>
</I>>><i> Thank for help,
</I>>><i> Łukasz Biedrycki
</I>>><i>
</I>>><i>
</I>>><i> _________________________________________________
</I>>><i> Extend mailing list
</I>>><i> <A HREF="https://lists.ninenines.eu/listinfo/extend">Extend at lists.ninenines.eu</A> <mailto:<A HREF="https://lists.ninenines.eu/listinfo/extend">Extend at lists.ninenines.eu</A>>
</I>>><i> <A HREF="https://lists.ninenines.eu/__listinfo/extend">https://lists.ninenines.eu/__listinfo/extend</A>
</I>>><i>
</I>>><i> <<A HREF="https://lists.ninenines.eu/listinfo/extend">https://lists.ninenines.eu/listinfo/extend</A>>
</I>>><i>
</I>>><i>
</I>>><i> --
</I>>><i> Loïc Hoguin
</I>>><i> <A HREF="http://ninenines.eu">http://ninenines.eu</A>
</I>>><i>
</I>>><i>
</I>>><i>
</I>><i> --
</I>><i> Loïc Hoguin
</I>><i> <A HREF="http://ninenines.eu">http://ninenines.eu</A>
</I>><i>
</I>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <<A HREF="http://lists.ninenines.eu/archives/extend/attachments/20140203/088e7e6a/attachment.html">http://lists.ninenines.eu/archives/extend/attachments/20140203/088e7e6a/attachment.html</A>>
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="000327.html">[99s-extend] Accept header in POST request
</A></li>
<LI>Next message: <A HREF="000329.html">[99s-extend] Accept header in POST request
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#328">[ date ]</a>
<a href="thread.html#328">[ thread ]</a>
<a href="subject.html#328">[ subject ]</a>
<a href="author.html#328">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://lists.ninenines.eu/listinfo/extend">More information about the Extend
mailing list</a><br>
</body></html>
