diff options
Diffstat (limited to 'archives/extend/attachments/20140203/e84f6223/attachment.html')
-rw-r--r-- | archives/extend/attachments/20140203/e84f6223/attachment.html | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/archives/extend/attachments/20140203/e84f6223/attachment.html b/archives/extend/attachments/20140203/e84f6223/attachment.html new file mode 100644 index 00000000..a936c1bd --- /dev/null +++ b/archives/extend/attachments/20140203/e84f6223/attachment.html @@ -0,0 +1,171 @@ +<tt> +<div dir="ltr">Perfect, thanks a lot!<div>Cheers,</div><div>Ł.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 8:15 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br><br> +<br> +<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<div class="im"><br> +<br> +<br><br> +<br><br> +On 02/03/2014 08:08 PM, Łukasz Biedrycki wrote:<br><br> +</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br> +Ok,<br><br> +it is more clear for me.<br><br> +<br><br> +Last question I have is about content_types_provided function.<br><br> +<br><br> +Is it safe to define it like this?<br><br> +<br><br> +content_types_provided(R, S) -><br></div><br> +ContentTypes = [{{<<"application">>, <<"json">>, '*'}, *undefined*}],<div class="im"><br><br> + {ContentTypes, Req, State}.<br><br> +<br><br> +Callback in content_types_provided is useless for POST requests, as it<br><br> +won’t be called.<br></div><br> +Is it safe to use *undefined *atom, to have a source code clearer?<div class="im"><br><br> +<br><br> +<br><br> +<br><br> +<br><br> +On Mon, Feb 3, 2014 at 7:37 PM, Loïc Hoguin <<a href="mailto:[email protected]" target="_blank">[email protected]</a><br></div><div class="im"><br> +<mailto:<a href="mailto:[email protected]" target="_blank">[email protected]</a>>> wrote:<br><br> +<br><br> + If Accept is sent and is different than text/html, yes.<br><br> +<br><br> + This is how HTTP is defined. If the client says it speaks only<br><br> + content-type X but you can only reply with content-type Y, you error<br><br> + out early and stop processing the request. On the other hand if the<br><br> + client doesn't say what content-type it speaks then the server can<br><br> + choose whichever one it wants.<br><br> +<br><br> +<br><br> + On 02/03/2014 07:26 PM, Łukasz Biedrycki wrote:<br><br> +<br><br> + My application sends both headers: “Content-type” and “Accept”<br><br> + header<br><br> + using POST method.<br><br> +<br><br> + For POST rest handler do I have to specify both:<br><br> + content_types_accepted<br><br> + and content_types_provided to manage this kind of request?<br><br> +<br><br> +<br><br> + On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <<a href="mailto:[email protected]" target="_blank">[email protected]</a><br><br> + <mailto:<a href="mailto:[email protected]" target="_blank">[email protected]</a>><br></div><div><div class="h5"><br> + <mailto:<a href="mailto:[email protected]" target="_blank">[email protected]</a> <mailto:<a href="mailto:[email protected]" target="_blank">[email protected]</a>>>> wrote:<br><br> +<br><br> + The content-type provided is relevant for any response, not<br><br> + just<br><br> + responses to GET requests. It defaults to text/html. If<br><br> + your client<br><br> + doesn't send that content-type, you have to define the<br><br> + callback.<br><br> +<br><br> + I notice that the documentation is incorrect about the relevant<br><br> + methods for this callback, I will open a ticket to fix it soon.<br><br> +<br><br> +<br><br> + On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:<br><br> +<br><br> + Hi,<br><br> + I have a rest handler that accepts POST and PUT<br><br> + requests with<br><br> + “application/json” content type.<br><br> +<br><br> + I have content_types_accepted function defined as follows:<br><br> +<br><br> + content_types_accepted(Req, State) -><br><br> +<br><br> +<br><br> + {[{‘application/json', from_json}], Req, State}.<br><br> +<br><br> +<br><br> +<br><br> + The problem I have is within a request that has two<br><br> + headers:<br><br> +<br><br> + *Content-type*: application/json<br><br> + *Accept*: application/json<br><br> +<br><br> + With this combination I receive *406*.<br><br> +<br><br> +<br><br> + You can repeat it with test:<br><br> +<br><br> + http_SUITE.erl:<br><br> + 1072 rest_postonly(Config) -><br><br> + 1073 Client = ?config(client, Config),<br><br> + 1074 Headers = [<br><br> + 1075 {<<"content-type">>, <<"text/plain">>},<br><br> + 1076 {<<"accept">>, <<"text/plain">>}<br><br> + 1077 ],<br><br> + 1078 {ok, Client2} =<br></div></div><br> + cowboy_client:request(<<"POST"<u></u>____>>,<div class="im"><br><br> +<br><br> + 1079 build_url("/postonly", Config), Headers,<br><br> + "12345",<br><br> + Client),<br><br> + 1080 {ok, 204, _, _} =<br></div><br> + cowboy_client:response(____<u></u>Client2).<div class="im"><br><br> +<br><br> +<br><br> + My solution to that was to add a content_types_provided<br><br> + function:<br><br> +<br><br> +<br><br> + content_types_provided(Req, State) -><br><br> +<br><br> +<br><br> + ContentTypes = [{{<<"application">>, <<"json">>, '*'},<br><br> + to_json}],<br><br> +<br><br> +<br><br> + {ContentTypes, Req, State}.<br><br> +<br><br> +<br><br> +<br><br> + But it is useless as *to_json* callback registered is<br><br> + not called<br><br> + anyhow.<br><br> +<br><br> + Adding *content_types_provided* function is a correct<br><br> + solution<br><br> + in this case?<br><br> +<br><br> + Or I am missing something here?<br><br> + “Accept” header is not relevant only in case of GET<br><br> + requests?<br><br> +<br><br> + Thank for help,<br><br> + Łukasz Biedrycki<br><br> +<br><br> +<br></div><br> + ______________________________<u></u>_____________________<div class="im"><br><br> + Extend mailing list<br><br> + <a href="mailto:[email protected]" target="_blank">[email protected]</a> <mailto:<a href="mailto:[email protected]" target="_blank">Extend@lists.<u></u>ninenines.eu</a>><br></div><br> + <mailto:<a href="mailto:Extend@lists." target="_blank">Extend@lists.</a>__<a href="http://ninenines.eu" target="_blank">ninenin<u></u>es.eu</a><br><br> + <mailto:<a href="mailto:[email protected]" target="_blank">Extend@lists.<u></u>ninenines.eu</a>>><br><br> + <a href="https://lists.ninenines.eu/____listinfo/extend" target="_blank">https://lists.ninenines.eu/___<u></u>_listinfo/extend</a><br><br> + <<a href="https://lists.ninenines.eu/__listinfo/extend" target="_blank">https://lists.ninenines.eu/__<u></u>listinfo/extend</a>><div class="im"><br><br> +<br><br> + <<a href="https://lists.ninenines.eu/__listinfo/extend" target="_blank">https://lists.ninenines.eu/__<u></u>listinfo/extend</a><br><br> + <<a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/<u></u>listinfo/extend</a>>><br><br> +<br><br> +<br><br> + --<br><br> + Loïc Hoguin<br><br> + <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br><br> +<br><br> +<br><br> +<br><br> + --<br><br> + Loïc Hoguin<br><br> + <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br><br> +<br><br> +<br><br> +</div></blockquote><div class="HOEnZb"><div class="h5"><br> +<br><br> +-- <br><br> +Loïc Hoguin<br><br> +<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br><br> +</div></div></blockquote></div><br></div><br> + +</tt> |