search

lostisland / faraday

Simple, but flexible HTTP client library, with support for multiple backends.
https://lostisland.github.io/faraday
MIT License
5.74k stars 976 forks source link

Missing HTTP 408 Request Timeout specific Faraday ClientError? #1511

Closed tisba closed 1 year ago

tisba commented 1 year ago

Hey there. I noticed that there is no specific Faraday::ClientError for HTTP 408:

https://github.com/lostisland/faraday/blob/be98e8ef6fd97513ce7d4967b796ef44d8b16bcf/lib/faraday/error.rb#L95-L121 does not contain an error for HTTP 408 Request Timeout. We recently seen this one a couple of times when talking to the Slack API for example.

Is there a reason this is not defined? If not, would you accept a PR to add this?

iMacTia commented 1 year ago

Hi @tisba 👋, no real reason for it to be missing, we simply add specific classes only for common errors. There's no downside to adding a new class that inherits from ClientError, so a PR that does that would be welcome.

Out of curiosity, are you experiencing this error under some special circumstances? I checked the RFC and it says that the error is normally sent on an "idle connection". That sounds like something hard to achieve with Ruby unless you're doing parallel/concurrent requests?

tisba commented 1 year ago

We're using the net_http_persistent adapter. Maybe that's because of this. We don't see it often, it would just be easier for us to handle with an exception and it would help to keep the code clean.

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/408:

[…]It is sent on an idle connection by some servers, even without any previous request by the client.

Which I found quite interesting, especially pre HTTP/2. I've been doing web stuff for a long time by now and lot's of performance testing… I've never seen HTTP 408 before 🤷

iMacTia commented 1 year ago

Which I found quite interesting, especially pre HTTP/2. That's exactly my thought and why I was curious to ask. If the connection is "idle" that would mean the ruby program is doing something else, meaning that it's probably not even listening to the connection.

The only way this could happen is if there was some sort of async listener (e.g. in a separate thread/fiber) or MAYBE, the way this works is that next time you fire a request on that connection, the adapter receives the 408 response that came earlier on?

Anyways, this is just curiosity 😄 it doesn't really stops adding the next error