Feedback for new user agent timeout needed
Sebastian Riedel
https://github.com/kraih/mojo/commit/d19d7aee330aa0e823ddc7560a8a63cc01c3f713#L2R775
--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us
sri
http://mojolicio.us/perldoc/Mojo/UserAgent#request_timeout
Michael Ludwig
> Latest version of the description should make it a bit easier to grok.
>
> http://mojolicio.us/perldoc/Mojo/UserAgent#request_timeout
What about LWPx::ParanoidAgent for guidance/inspiration/reuse?
https://metacpan.org/module/LWPx%3A%3AParanoidAgent
Michael
Sebastian Riedel
What about it?
Michael Ludwig
> > What about LWPx::ParanoidAgent for guidance/inspiration/reuse?
>
> What about it?
Well, you wrote: "I know a timeout like this has been requested a few
times, but i'm not so sure about the actual implementation." Where by
"like this" you seem to refer to "Maximum amount of time in seconds
sending the request and receiving the whole response may take before
getting canceled" as in the POD pointer you gave. So I thought I'd point
you to LWPx::ParanoidAgent, which I think does just that, and would be
relevant for guidance/inspiration/reuse. But maybe I got you wrong.
Michael
Sebastian Riedel
> relevant for guidance/inspiration/reuse. But maybe I got you wrong.
What exactly do you think we should be guided/inspired by or reuse?
sri
Michael Ludwig
> > So I thought I'd point you to LWPx::ParanoidAgent, which
> > I think does just that, and would be relevant for
> > guidance/inspiration/reuse. But maybe I got you wrong.
>
> What exactly do you think we should be guided/inspired by or reuse?
Guess this was pretty clear in my last mail, wasn't it:
Well, you wrote: "I know a timeout like this has been requested a
few times, but i'm not so sure about the actual implementation."
Where by "like this" you seem to refer to "Maximum amount of time
in seconds sending the request and receiving the whole response
may take before getting canceled" as in the POD pointer you gave.
With regard to the timeout issue, compare:
This class protects you from connecting to internal IP ranges
(unless you whitelist them), hostnames/IPs that you blacklist,
remote webserver tarpitting your process (the timeout parameter
is changed to be a global timeout over the entire process), and
all combinations of redirects and DNS tricks to otherwise tarpit
and/or connect to internal resources.
https://metacpan.org/module/LWPx%3A%3AParanoidAgent
That bit of doc is misunderstandable in that the phrase "over the
entire process" might be taken to mean a process-wide timeout such
as offered by alarm(), which is not what the module does. Rather,
the wording could have been "over the whole request/response cycle".
So going back to *your* POD bit ("Maximum amount of time in seconds
sending the request and receiving the whole response may take
before getting canceled, defaults to 0."), it seems you're dealing
with the same problem, which is why the LWPx::ParanoidAgent attempt
could be thought to be of interest to you as you're asking for
feedback about the issue on this list.
Now if this hasn't clarified the issue, dann bin ich mit meinem
Latein am Ende.
Michael
Sebastian Riedel
> Latein am Ende.
Ok, i think i get it now, you're basically expecting protection from malicious hosts. I was afraid it might give that impression, request_timeout was just meant as a helper for interacting with friendly backend web services that take a little too long.
sri
kitt kitt
And it's gone again.'
Why? May be not much people using Mojo read this group, but they found this method usefull. Later.
sri
> method usefull. Later.
or IRC, if it's not positive the feature doesn't make it into a
release for wider exposure.
--
sebastian
sri
welcome to speak up in favor of it in this thread or open a ticket at
https://github.com/kraih/mojo/issues?sort=created&direction=desc&state=open.
--
sebastian
Roland Lammel
For me it seems confusion is mostly coming from what actually is meant by the timeout.
I found the explaination very good and to the point, although my initial impression when reading request timeout was: Request timeout limits the time for the final response from the server adter the request has been sent. Redirects will not reset the timer, so you can expect your content to be available in the response or the request being canceled and an error is thrown.
Only difference would be the timeout is actually not reset for redirects, which i personally wozld prefer. It's usually the content im interested to receive "in time".
So i would vote for having a timeout built in. But woild like to see more votes.
+rl
Roland Lammel
Sent from an Android mobile.
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To post to this group, send email to mojol...@googlegroups.com.
To unsubscribe from this group, send email to mojolicious...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mojolicious?hl=en.
Sebastian Riedel
This would be very very hard to implement and is very likely to interfere with our real-time features.
sri
https://github.com/kraih/mojo/commit/0ee2405f8701271132b58cc05ce4d68a1fd3ecd9
sri
connection.
https://github.com/kraih/mojo/commit/ebb6741e0e72133467b58ecdd022d06d5cdcd654#L0R778