summaryrefslogtreecommitdiffstats
path: root/archives/extend/2014-May.txt
blob: 2b42dd7317b77fa9befb3177b37aae22179449f3 (plain) (blame)
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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
From janos.n.hary at gmail.com  Sun May  4 09:59:21 2014
From: janos.n.hary at gmail.com (Janos Hary)
Date: Sun, 4 May 2014 09:59:21 +0200
Subject: [99s-extend] Gracefully stop Ranch
Message-ID: <[email protected]>

All!

I implemented a protocol as a ranch_protocol. It handles long running
sessions. At some point I'd like to stop my server accepting new
connections, but allow all open sessions to finish. Then I need to know when
all the open sessions (if any) finished.

What would be the correct strategy to implement this?

Thanks,
Janos



From paulo.ferraz.oliveira at gmail.com  Tue May 20 18:27:58 2014
From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira)
Date: Tue, 20 May 2014 17:27:58 +0100
Subject: [99s-extend] REST responses
Message-ID: <CA+dV7cR9M-5dq2kYJgowrodDbCEQ0aAnkZKyQmw07hmAJXmc=A@mail.gmail.com>

Hello.

First of all, thanks for the great work you've done with cowboy. I've been
using it with a fait amount of success and I'm a fairly new Erlang
developer. I'm mainly interested in the REST "interface" of the application
and its way of doing RESTful things, and I like the way you did it (what
with all the content_types_provided, service_available, etc. functions).
I've tested the way the system reacted to the different Accept,
Content-Type, etc. headers and always got very well-opinionated responses
(406, 415, ...).

A couple of questions remain though (I'm sorry if they've been asked
already but I've searched the web for answers and read the available docs
and couldn't find them):

1. is it expected that, if I use cowboy_req:reply/2 in a GET handler
(coming from content_types_provided), the onresponse/4 hook be called
twice? I guess one is due to the reply and the other one due to the
workflow of the request, but is there a way to prevent the second execution?

2. if I want to JSON-parse ALL my requests should I a) use the onrequest/1
hook or b) do this on a per-request basis? Because I'd like to reply with a
400 ASAP but keep going if the JSON validates (I'm going to use JSON-schema
for validating input); and, if possible, have the JSON-parsed body stored
somewhere for future manipulation.

3. I haven't seen examples that made use of the State (from the function
returns). When should I use this instead of the Request metadata? I'd like
to be able to set a generic error state for a request (either in meta ou
State) and that have a "standard" error response be created at a later time
(in a unique function, for example - e.g. onresponse/4).

4. is there anything like a catch-all exception handler? I'd like to catch
exceptions that occur anywhere so I could log them and analyze them at a
later moment.

I'm probably abusing the onresponse/onrequest hooks already, so your
answers should help me clarify this.

Thanks.

- Paulo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20140520/cf7632e9/attachment.html>

From paulo.ferraz.oliveira at gmail.com  Tue May 20 20:32:10 2014
From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira)
Date: Tue, 20 May 2014 19:32:10 +0100
Subject: [99s-extend] 202 for POST or PUT
Message-ID: <CA+dV7cRUn3oQ34DaZbPaY3TcfEJUO4iq8Gk6sJuLqzGGA4MT8g@mail.gmail.com>

Hi.

Do you think it should be possible to generate a 202 for a POST or a PUT?
Is it something that will be implemented in a future version?

Many thanks.

- Paulo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20140520/699b72b3/attachment.html>

From essen at ninenines.eu  Tue May 20 20:46:02 2014
From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
Date: Tue, 20 May 2014 20:46:02 +0200
Subject: [99s-extend] REST responses
In-Reply-To: <CA+dV7cR9M-5dq2kYJgowrodDbCEQ0aAnkZKyQmw07hmAJXmc=A@mail.gmail.com>
References: <CA+dV7cR9M-5dq2kYJgowrodDbCEQ0aAnkZKyQmw07hmAJXmc=A@mail.gmail.com>
Message-ID: <[email protected]>

Hi,

On 05/20/2014 06:27 PM, Paulo F. Oliveira wrote:
> Hello.
>
> First of all, thanks for the great work you've done with cowboy. I've
> been using it with a fait amount of success and I'm a fairly new Erlang
> developer. I'm mainly interested in the REST "interface" of the
> application and its way of doing RESTful things, and I like the way you
> did it (what with all the content_types_provided, service_available,
> etc. functions). I've tested the way the system reacted to the different
> Accept, Content-Type, etc. headers and always got very well-opinionated
> responses (406, 415, ...).
>
> A couple of questions remain though (I'm sorry if they've been asked
> already but I've searched the web for answers and read the available
> docs and couldn't find them):
>
> 1. is it expected that, if I use cowboy_req:reply/2 in a GET handler
> (coming from content_types_provided), the onresponse/4 hook be called
> twice? I guess one is due to the reply and the other one due to the
> workflow of the request, but is there a way to prevent the second execution?

If you reply from a callback you must call {halt, Req, State} to stop 
processing.

> 2. if I want to JSON-parse ALL my requests should I a) use the
> onrequest/1 hook or b) do this on a per-request basis? Because I'd like
> to reply with a 400 ASAP but keep going if the JSON validates (I'm going
> to use JSON-schema for validating input); and, if possible, have the
> JSON-parsed body stored somewhere for future manipulation.

It makes little sense to do it before the accept callback you define. 
Not only because you will duplicate content-type checks and whatnot, but 
also because you don't actually win anything from doing this. If you are 
using JSON, then JSON processing will take infinitely more resources 
than the REST code.

> 3. I haven't seen examples that made use of the State (from the function
> returns). When should I use this instead of the Request metadata? I'd
> like to be able to set a generic error state for a request (either in
> meta ou State) and that have a "standard" error response be created at a
> later time (in a unique function, for example - e.g. onresponse/4).

State is for the functions within the current module. Look at 
cowboy_static for an example.

> 4. is there anything like a catch-all exception handler? I'd like to
> catch exceptions that occur anywhere so I could log them and analyze
> them at a later moment.

You can add your own error_logger handler, or use something like lager. 
All errors end up sending a message to error_logger.

> I'm probably abusing the onresponse/onrequest hooks already, so your
> answers should help me clarify this.

Sounds like it!

> Thanks.
>
> - Paulo
>
>
> _______________________________________________
> Extend mailing list
> Extend at lists.ninenines.eu
> https://lists.ninenines.eu/listinfo/extend
>

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


From essen at ninenines.eu  Tue May 20 20:47:16 2014
From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
Date: Tue, 20 May 2014 20:47:16 +0200
Subject: [99s-extend] 202 for POST or PUT
In-Reply-To: <CA+dV7cRUn3oQ34DaZbPaY3TcfEJUO4iq8Gk6sJuLqzGGA4MT8g@mail.gmail.com>
References: <CA+dV7cRUn3oQ34DaZbPaY3TcfEJUO4iq8Gk6sJuLqzGGA4MT8g@mail.gmail.com>
Message-ID: <[email protected]>

202 is only well defined for the DELETE method so there's no plan to add 
something for other methods at this point. You can of course reply 
directly if needed.

On 05/20/2014 08:32 PM, Paulo F. Oliveira wrote:
> Hi.
>
> Do you think it should be possible to generate a 202 for a POST or a
> PUT? Is it something that will be implemented in a future version?
>
> Many thanks.
>
> - Paulo
>
>
> _______________________________________________
> Extend mailing list
> Extend at lists.ninenines.eu
> https://lists.ninenines.eu/listinfo/extend
>

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


From paulo.ferraz.oliveira at gmail.com  Tue May 20 23:41:15 2014
From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira)
Date: Tue, 20 May 2014 22:41:15 +0100
Subject: [99s-extend] REST responses
Message-ID: <CA+dV7cTrbQd-widnjH5CjsYum=ASwax7VxtAUn_9BVONp2MMuA@mail.gmail.com>

Hi, Lo?c.

Thanks for having taken the time to reply. In some of my questions I think
I didn't explain myself correctly so I'll give it another go.


On 20 May 2014 19:46, Lo?c Hoguin <essen at ninenines.eu> wrote:

> Hi,
>
>
> On 05/20/2014 06:27 PM, Paulo F. Oliveira wrote:
>
>> Hello.
>>
>> First of all, thanks for the great work you've done with cowboy. I've
>> been using it with a fait amount of success and I'm a fairly new Erlang
>> developer. I'm mainly interested in the REST "interface" of the
>> application and its way of doing RESTful things, and I like the way you
>> did it (what with all the content_types_provided, service_available,
>> etc. functions). I've tested the way the system reacted to the different
>> Accept, Content-Type, etc. headers and always got very well-opinionated
>> responses (406, 415, ...).
>>
>> A couple of questions remain though (I'm sorry if they've been asked
>> already but I've searched the web for answers and read the available
>> docs and couldn't find them):
>>
>> 1. is it expected that, if I use cowboy_req:reply/2 in a GET handler
>> (coming from content_types_provided), the onresponse/4 hook be called
>> twice? I guess one is due to the reply and the other one due to the
>> workflow of the request, but is there a way to prevent the second
>> execution?
>>
>
> If you reply from a callback you must call {halt, Req, State} to stop
> processing.


Got it!


> 2. if I want to JSON-parse ALL my requests should I a) use the
>> onrequest/1 hook or b) do this on a per-request basis? Because I'd like
>> to reply with a 400 ASAP but keep going if the JSON validates (I'm going
>> to use JSON-schema for validating input); and, if possible, have the
>> JSON-parsed body stored somewhere for future manipulation.
>>
>
> It makes little sense to do it before the accept callback you define. Not
> only because you will duplicate content-type checks and whatnot, but also
> because you don't actually win anything from doing this. If you are using
> JSON, then JSON processing will take infinitely more resources than the
> REST code.


OK, I'll probably stick with a "helper" function that'll do this for me and
reply in case there are validation errors.
I only found the flow diagrams for the requests today after I had sent this
message, and they helped a lot.


> 3. I haven't seen examples that made use of the State (from the function
>> returns). When should I use this instead of the Request metadata? I'd
>> like to be able to set a generic error state for a request (either in
>> meta ou State) and that have a "standard" error response be created at a
>> later time (in a unique function, for example - e.g. onresponse/4).
>>
>
> State is for the functions within the current module. Look at
> cowboy_static for an example.


State allows me to, well, keep state, for a request "travelling" through
functions, right, and I can change it whenever I want just before returning
from a function that is executed prior to another one (the only function
for which this doesn't seem to make since is the last one cowboy calls
before actually replying to the client)? At the same time, so does the
request meta, from what I understood from the manual. So what is the
difference between one and the other and when would you recommend one or
the other.

4. is there anything like a catch-all exception handler? I'd like to
>> catch exceptions that occur anywhere so I could log them and analyze
>> them at a later moment.
>>
>
> You can add your own error_logger handler, or use something like lager.
> All errors end up sending a message to error_logger.


I'll do this, thanks.


> I'm probably abusing the onresponse/onrequest hooks already, so your
>> answers should help me clarify this.
>>
>
> Sounds like it!
>
> Thanks.
>>
>> - Paulo
>>
>>
>> _______________________________________________
>> Extend mailing list
>> Extend at lists.ninenines.eu
>> https://lists.ninenines.eu/listinfo/extend
>>
>>
> --
> Lo?c Hoguin
> http://ninenines.eu
>

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20140520/32454f85/attachment.html>

From essen at ninenines.eu  Tue May 20 23:52:21 2014
From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
Date: Tue, 20 May 2014 23:52:21 +0200
Subject: [99s-extend] REST responses
In-Reply-To: <CA+dV7cTrbQd-widnjH5CjsYum=ASwax7VxtAUn_9BVONp2MMuA@mail.gmail.com>
References: <CA+dV7cTrbQd-widnjH5CjsYum=ASwax7VxtAUn_9BVONp2MMuA@mail.gmail.com>
Message-ID: <[email protected]>

> State allows me to, well, keep state, for a request "travelling" through
> functions, right, and I can change it whenever I want just before
> returning from a function that is executed prior to another one (the
> only function for which this doesn't seem to make since is the last one
> cowboy calls before actually replying to the client)? At the same time,
> so does the request meta, from what I understood from the manual. So
> what is the difference between one and the other and when would you
> recommend one or the other.

They have different purposes. Meta values are additional information 
about the request. You're not supposed to set them except in special 
circumstances, either because you have your own custom protocol like 
cowboy_rest, or because there's no other way to pass state forward.

Don't think about it, always use State.

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