27 Nov
2008
27 Nov
'08
1:33 p.m.
Hello,
is there a way to add a Retry-After header to a 503 response i'm sending out
using t_reply?
Use case: t_relay creates an internal 408 on timeout. From failure-route, i
want to pass it upstream as 503 with retry-after header. Changing the reply
to 503 using t_reply works, but how to add the header?
The reply obviously doens't pass through any reply_route.
--
Greetings,
Alex Hermann
27 Nov
27 Nov
1:38 p.m.
On Thursday 27 November 2008, Alex Hermann wrote:
is there a way to add a Retry-After header to a 503
response i'm sending
out using t_reply?
Use case: t_relay creates an internal 408 on timeout. From failure-route, i
want to pass it upstream as 503 with retry-after header. Changing the reply
to 503 using t_reply works, but how to add the header?
The reply obviously doens't pass through any reply_route.
Hi Alex,
have you tried using append_to_reply("Retry-After: 120\n"); before the
sl_send_reply or t_reply?
Cheers,
Henning
3:49 p.m.
On Thursday 27 November 2008, Henning Westerholt wrote:
On Thursday 27 November 2008, Alex Hermann wrote:
Well, as it is marked to not be usable from failure route I hadn't considered
it.
The following fragment seems to work, so I'll assume it is safe to call
append_to_reply from failure_route itself. Attached (tested) patch does this,
please apply.
<failure route>
if (t_local_replied("all")) {
route(78);
t_reply("503", "Service Unavailable");
}
route[78] {
append_to_reply("Retry-After: 53\r\n");
return;
}
--
Met vriendelijke groet,
Alex Hermann
SpeakUp
T: 088-SPEAKUP (088-7732587)
F: 088-7732588
is there a way to add a Retry-After header to a
503 response i'm sending
out using t_reply?
Use case: t_relay creates an internal 408 on timeout. From failure-route,
i want to pass it upstream as 503 with retry-after header. Changing the
reply to 503 using t_reply works, but how to add the header?
The reply obviously doens't pass through any reply_route.
Hi Alex,
have you tried using append_to_reply("Retry-After: 120\n"); before the
sl_send_reply or t_reply? 
6:52 p.m.
On 11/27/08 16:49, Alex Hermann wrote:
On Thursday 27 November 2008, Henning Westerholt
wrote:
yes, it is safe. It is important to
understand that this operation
affects replies generated from request by kamailio, not the ones that
pass through -- one can use append_hf() in onreply_route to add headers
to these kind of replies.
I will apply the patch, thanks.
Cheers,
Daniel
On Thursday 27 November 2008, Alex Hermann
wrote:
Well, as it is marked to not be usable from failure route I hadn't considered
it.
The following fragment seems to work, so I'll assume it is safe to call
append_to_reply from failure_route itself. is there a way to add a Retry-After header to a
503 response i'm sending
out using t_reply?
Use case: t_relay creates an internal 408 on timeout. From failure-route,
i want to pass it upstream as 503 with retry-after header. Changing the
reply to 503 using t_reply works, but how to add the header?
The reply obviously doens't pass through any reply_route.
Hi Alex,
have you tried using append_to_reply("Retry-After: 120\n"); before the
sl_send_reply or t_reply?
Attached (tested) patch does this,
please apply.
<failure route>
if (t_local_replied("all")) {
route(78);
t_reply("503", "Service Unavailable");
}
route[78] {
append_to_reply("Retry-After: 53\r\n");
return;
}
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
--
Daniel-Constantin Mierla
http://www.asipto.com
28 Nov
28 Nov
11:02 a.m.
On Thursday 27 November 2008, Daniel-Constantin Mierla wrote:
Thank you Daniel,
Henning
[..]
The following fragment seems to work, so I'll assume it is safe to call
append_to_reply from failure_route itself.
yes, it is safe. It is important to understand that this operation
affects replies generated from request by kamailio, not the ones that
pass through -- one can use append_hf() in onreply_route to add headers
to these kind of replies.
I will apply the patch, thanks.
5635
days inactive
5636
days old
4 comments
3 participants
participants (3)
-
Alex Hermann -
Daniel-Constantin Mierla -
Henning Westerholt