Configure Guzzle clients #64
Conversation
| 'handler' => $this->app['hypothesis.guzzle.handler'], | ||
| 'timeout' => 0.9, |
There was a problem hiding this comment.
We want fast failures as Journal has a 1-second timeout. This has to be less than that otherwise Annotations won't see an error (Journal will just have disconnected).
There was a problem hiding this comment.
It's reasonable to think that the rest of the code being executed by this service will have a 100ms overhead, anyway
| @@ -224,7 +224,10 @@ public function __construct(string $environment = 'dev') | |||
|
|
|||
| return new Client([ | |||
| 'base_uri' => $this->app['hypothesis']['api_url'], | |||
| 'connect_timeout' => 0.5, | |||
| 'decode_content' => 'gzip', | |||
There was a problem hiding this comment.
Probably worth doing as this is external.
There was a problem hiding this comment.
Just confirmed that the current hypothesis-dummy supports this for testing (happens at the cURL level, which the local tests don't hit), though elifesciences/hypothesis-dummy#3 will turn it off (removes Nginx; could add it to the PHP code?).
There was a problem hiding this comment.
Should degrade automatically if the response is not gzipped as there's no Content-Encoding header? Which would be a difference between end2end and prod but not critical?
There was a problem hiding this comment.
Yep, cURL handles it all.
There was a problem hiding this comment.
As it stands, this should not explode with any version of hypothesis-dummy then
|
We might want to use HTTP/2 for Hypothesis (their API supports it), but not sure what to make of guzzle/guzzle#1249 (means upgrading cURL anyhow). |
|
Ignoring HTTP/2 for now, will need some experimentation. (Opened ELPP-3406.) |
No description provided.