1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
From amol at hatwar.org Sun Oct 5 04:56:58 2014
From: amol at hatwar.org (Amol Hatwar)
Date: Sun, 5 Oct 2014 08:26:58 +0530
Subject: [99s-extend] Prevent resource creation on POST
Message-ID: <[email protected]>
Hello,
I was recently tinkering with cowboy_rest and found that there is no way prevent resource creation in a POST request when it already exists. Either that, or I'm probably not doing something right or don't know enough...
Here's what I have running:
A user tries to signup with a post request. To be successful, the username has to be unique. The resource_exists/2 method responds with proper true and false values by looking at the request body.
Here's what I want done:
Iff the resource_exists callback returns true, I don't want the AcceptResource callback to run at all. Instead, I want to send a 4XX status and halt. Is there a canonical way of doing this?
Cheers,
AH
From essen at ninenines.eu Sun Oct 5 09:49:00 2014
From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
Date: Sun, 05 Oct 2014 10:49:00 +0300
Subject: [99s-extend] Prevent resource creation on POST
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
If resource_exists = true, then POST doesn't create but update the
resource at the given URI. If what you are doing is something like
write-once resources then you will have to reject these cases manually
by returning halt at some point.
On 10/05/2014 05:56 AM, Amol Hatwar wrote:
> Hello,
>
> I was recently tinkering with cowboy_rest and found that there is no way prevent resource creation in a POST request when it already exists. Either that, or I'm probably not doing something right or don't know enough...
>
> Here's what I have running:
> A user tries to signup with a post request. To be successful, the username has to be unique. The resource_exists/2 method responds with proper true and false values by looking at the request body.
>
> Here's what I want done:
> Iff the resource_exists callback returns true, I don't want the AcceptResource callback to run at all. Instead, I want to send a 4XX status and halt. Is there a canonical way of doing this?
>
> Cheers,
>
> AH
> _______________________________________________
> Extend mailing list
> Extend at lists.ninenines.eu
> https://lists.ninenines.eu/listinfo/extend
>
--
Lo?c Hoguin
http://ninenines.eu
From stefan.strigler at gmail.com Tue Oct 14 10:05:53 2014
From: stefan.strigler at gmail.com (Stefan Strigler)
Date: Tue, 14 Oct 2014 10:05:53 +0200
Subject: [99s-extend] PUT on new resource and status 201
Message-ID: <CAE7UswcWMj-voOs4eSbYxNyfkHZ8anCeUr6JyBGU+RhODk5Nig@mail.gmail.com>
Hey,
just subscribed yesterday and now that's already my first question.
I'm referring to
http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you
have a PUT on a new resource the diagram suggests that the response's
status code depends on whether you've set a location and/or body. But when
looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would always
return a 201. No matter what. I think the code is right, but the diagram
needs to be fixed.
But then I'm not totally sure how to interpret
http://tools.ietf.org/html/rfc2616#section-10.2.2 which states
The newly created resource can be referenced by the URI(s)
returned in the entity of the response, with the most specific URI
for the resource given by a Location header field.
Because currently it is totally possible to not have a location header
set (just as no body) for the response. In my opinion the current code
behaves good enough and it's up to the service to ensure the
requirements as stated by the RFC. Should cowboy enforce a header
field? Should it try to figure that out on its own?
Regards,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20141014/d89bced6/attachment.html>
From lists at tuli.pe Tue Oct 14 10:42:54 2014
From: lists at tuli.pe (Camille Troillard)
Date: Tue, 14 Oct 2014 10:42:54 +0200
Subject: [99s-extend] PUT on new resource and status 201
In-Reply-To: <CAE7UswcWMj-voOs4eSbYxNyfkHZ8anCeUr6JyBGU+RhODk5Nig@mail.gmail.com>
References: <CAE7UswcWMj-voOs4eSbYxNyfkHZ8anCeUr6JyBGU+RhODk5Nig@mail.gmail.com>
Message-ID: <[email protected]>
Hi Stefan,
On 14 Oct 2014, at 10:05, Stefan Strigler <stefan.strigler at gmail.com> wrote:
> just subscribed yesterday and now that's already my first question.
>
> I'm referring to http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you have a PUT on a new resource the diagram suggests that the response's status code depends on whether you've set a location and/or body.
This is correct, I have experience this behaviour on Cowboy 1.0.0 and 2.0.0-pre.1.
> But when looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would always return a 201. No matter what. I think the code is right, but the diagram needs to be fixed.
Could you be more specific?
I?m afraid it is not how it works for me.
> But then I'm not totally sure how to interpret http://tools.ietf.org/html/rfc2616#section-10.2.2 which states
>
> The newly created resource can be referenced by the URI(s)
> returned in the entity of the response, with the most specific URI
> for the resource given by a Location header field.
>
> Because currently it is totally possible to not have a location header set (just as no body) for the response. In my opinion the current code behaves good enough and it's up to the service to ensure the requirements as stated by the RFC. Should cowboy enforce a header field? Should it try to figure that out on its own?
I think how Cowboy does is best at the moment.
I like to have the freedom to specify myself the Location, especially when PUT-ting new resources.
A bit off topic, I think this article is interesting regarding RFC-2616.
https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead
Given that, you might want to have a look at RFC-7231, section 3.1.4.2:
http://tools.ietf.org/html/rfc7231#section-3.1.4.2.
Camille
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20141014/77f74bf0/attachment-0001.html>
From essen at ninenines.eu Tue Oct 14 12:38:08 2014
From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
Date: Tue, 14 Oct 2014 12:38:08 +0200
Subject: [99s-extend] PUT on new resource and status 201
In-Reply-To: <CAE7UswcWMj-voOs4eSbYxNyfkHZ8anCeUr6JyBGU+RhODk5Nig@mail.gmail.com>
References: <CAE7UswcWMj-voOs4eSbYxNyfkHZ8anCeUr6JyBGU+RhODk5Nig@mail.gmail.com>
Message-ID: <[email protected]>
Hi,
On 10/14/2014 10:05 AM, Stefan Strigler wrote:
> I'm referring to
> http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you
> have a PUT on a new resource the diagram suggests that the response's
> status code depends on whether you've set a location and/or body. But
> when looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would
> always return a 201. No matter what. I think the code is right, but the
> diagram needs to be fixed.
Yes it looks like you are on to something there. Please open a ticket
and I will look later on. There's another change near that area that
needs to be made with POST, I will look at both at the same time.
> But then I'm not totally sure how to interpret
> http://tools.ietf.org/html/rfc2616#section-10.2.2 which states
>
> The newly created resource can be referenced by the URI(s)
> returned in the entity of the response, with the most specific URI
> for the resource given by a Location header field.
>
>
> Because currently it is totally possible to not have a location header set (just as no body) for the response. In my opinion the current code behaves good enough and it's up to the service to ensure the requirements as stated by the RFC. Should cowboy enforce a header field? Should it try to figure that out on its own?
201 does not require a location header if the resource is created at the
path indicated by the request. Specifying a different URI is a rare
occurrence with PUT, it should only occur if you create the resource on
a different domain name (think a CDN pushing the file to a subdomain).
And as Camille stated, forget RFC 2616, the various RFCs from httpbis is
where it's at now.
--
Lo?c Hoguin
http://ninenines.eu
From David.Hiers at cdk.com Fri Oct 31 15:43:22 2014
From: David.Hiers at cdk.com (Hiers, David)
Date: Fri, 31 Oct 2014 14:43:22 +0000
Subject: [99s-extend] Cowboy, IE9, and HTTPS
Message-ID: <[email protected]>
Hello,
Has anyone had trouble getting IE9 connecting to Cowboy over HTTPS?
We're using Cowboy embedded in MongooseIM, and IE9 is giving us fits.
Thanks,
David
----------------------------------------------------------------------
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20141031/fc6724a7/attachment.html>
|
