HttpMethodsClient constructor options

[dbu]

We should have constructor options to control the HttpMethodsClient behaviour

• default_headers => plugin
• base_url (domain and start path, to be combined with the send() methods, see also https://github.com/php-http/httplug/issues/36)
• preserve_host (whether to update the default HOST header from the $uri argument if an absolute url is passed, but no explicit HOST header)

[joelwurtz]

Should we not do this in the Plugin and attach the PluginClient to the HttpMethodsClient instead ?

[dbu]

i am not sure if a request can be instantiated with a relative path or without domain. if it can, then yes. not sure at which point validation happens, or if PSR-7 says anything about that. if some implementations validate at construction time, we do need something here.

but indeed, what can be done as plugin should really be plugin.

[sagikazarmark]

attach the PluginClient to the HttpMethodsClient instead

What does attach mean in this context?

Even if there are colliding features in the PluginClient and the MethodsClient, I would say they should not be coupled. With other words things which are necessary to have in the MethodsClient, should be done there.

[dbu]

for preserve_host i don't know if this can be done in a plugin. maybe its an option on the default headers plugin to set the HOST from the url.

@sagikazarmark for things plugins can do i agree that we should use a configured PluginClient inside the HttpMethodsClient rather than duplicating logic in HttpMethodsClient.

[sagikazarmark]

What I am saying: MethodsClient should work on it's own without requiring PluginClient. Otherwise it is hard coupling.

[dbu]

i agree. we just should not provide functionality in this client that plugins can already do.

On 29.10.2015 10:45, Márk Sági-Kazár wrote:

What I am saying: MethodsClient should work on it's own without requiring PluginClient. Otherwise it is hard coupling.

— Reply to this email directly or view it on GitHub https://github.com/php-http/utils/issues/11#issuecomment-152130158.

Liip AG // Agile Web Development // T +41 43 500 39 80 CH-8005 Zurich // PGP 0xA581808B // www.liip.ch

[joelwurtz]

i am not sure if a request can be instantiated with a relative path or without domain. if it can, then yes. not sure at which point validation happens, or if PSR-7 says anything about that. if some implementations validate at construction time, we do need something here.

Don't remind that PSR-7 set something about that, if using the socket-client you can have a relative path only in the request which is enough as there may be no host needed (like for a unix socket : unix:///var/run/server.sock)

[sagikazarmark]

In PSR7 Host is required I think.

[joelwurtz]

PSR-7 :

During construction, implementations MUST attempt to set the Host header from a provided URI if no Host header is provided.

RequestInterface::withUri() will, by default, replace the returned request's Host header with a Host header matching the host component of the passed UriInterface.

It say "must attempt", so they need to try but doesn't say something when the attempt fail

And their examples show case when the host header is empty, so it is not required and can be empty

[sagikazarmark]

Ah, ok. Thanks for clarifing that.