Michael Wallner
Michael Wallner
Any insight here @Jan-E @cmb69? Sorry for cold-tagging, but I'm pretty lost on windows issues...
> I can confirm that [86b8a43](https://github.com/m6w6/ext-http/commit/86b8a4396d03ad6161ba3d05dd4986521ec7e182) solves the reported issue, but it doesn't look like a proper fix for the actual problem; why would failing to set an unsupported option...
Hm, yeah, that origins from importing headers from the (CGI) environment where header names look like `HTTP_ACCEPT_ENCODING`.
Looks like Apache as well as nginx drop headers with underscores.
For Apache+mod_php: only with `apache_request_headers()`, but not through the environment, i.e. `$_SERVER`.
Implementing this as property was probably a bad idea, so, should we add a method and deprecate the public property?
If the main concern is setting the encoding for an async connection, it's probably best to use the client_encoding connection string parameter: http://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-CONNECT-CLIENT-ENCODING
- [ ] Throw an exception on invalid property access (i.e. `zend_replace_error_handling` in `php_pq_object_read_prop`/`php_pq_object_write_prop`) - [ ] Deprecate all connection sensitive properties and introduce getters/setters with exceptions - [ ]...
Has there been an outcome/consensus?
This is really a silly test, which may fail in a slow environment.