To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/V0tlGy9XPLMJ.--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
Regarding addHeader/addHeaders:
I don't feel these methods are ambiguous. In Guzzle, the addHeader()
and addHeaders() methods will add new headers if they are not already
present on a message or append to an existing header if the header was
already present.
Interfaces should not contain __constructors.
How important is it that the Request and Response know about each other? I sorta feel like they really don't *need* to know about each other but maybe I'm missing some common use cases there? If they don't *need* to know about each other I think I'd prefer to keep the interfaces simpler and drop them.
Are there use cases for end-users creating Response objects? That seems like the responsibility of a client provided by a vendor and since each vendor is going to probably have highly specialized handling in the creation of response objects I'm not sure what utility there is in defining a Response factory. Maybe it would make sense for completeness so I would not be opposed to it.
Interfaces should not contain __constructors.I agree with this.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/VMA1f5_tGG8J.
Interfaces don't define how you have to initialize (or cleanup, in case of destructors) an object. They just define its expected behavior of it once it's already initialized. There's enough docs on it on the web. It's even disallowed to have constructors in interfaces in some OO languages.
Anything IOC related becomes really hard when you got an interface that defines a constructor. Constructors vary a lot depending on implementations, and usually are not really related with how the object behaves once instantiated.
Can we cut this part of the discussion on this particular thread? It's very OT :)
1. How will multi-valued headers be added, retrieved, etc? Some people
think every call to `getHeader()` should return an array. Guzzle uses
a Header class to store headers so that they are case-insensitive, can
be used as strings, and can be iterated like an array:
https://github.com/guzzle/guzzle/blob/master/src/Guzzle/Http/Message/Header.php
2. How will transactional history of an HTTP request/response be
handled (e.g. redirects and requests issued to return a response)?
People previously recommended implementing a `getPreviousResponse()`
method on a response class. Guzzle uses this implementation and it
allows you to see every request/response issued that led to a
particular response. Maybe this is outside the scope of this PSR.
3. I'd either like to see a URL class be defined or to add the
following methods to a request: get/setQuery() (would return a query
string array/object/etc), get/setPath(), get/setHost(), get/setPort(),
get/setScheme() (e.g. http, https, etc), get/setPassword(),
get/setUsername(), etc. This is very helpful for both client and
server applications that would use this PSR.
4. How will query strings be represented? Should everything just be
passed into the request's URL as a string, or should we have
functionality to provide a more associative array type functionality?
One thing to keep in mind is that different servers use different
representations of multi-valued query string variables. Guzzle uses a
QueryString object to handle this:
https://github.com/guzzle/guzzle/blob/master/src/Guzzle/Http/QueryString.php
Simensen: I think the idea of creating mutable vs immutable requests
is really complicated and would make it hard to add functionality to
an HTTP client implemented with this proposed interface. I also think
clients, observers, or whatever else people choose to implement on top
of these PSRs should be able to modify a request or response as needed
(take a look at Guzzle's plugin system for examples).
I probably will have a whole slew of other questions about this PSR,
but it's New Year's Eve so I gotta run for now.
-Michael
I've just committed the package to https://github.com/thewilkybarkid/psr-http. It uses the proposal as it currently is, but as it obviously will change I'll try to keep it as up to date as possible (large changes might take a while to do!).
Chris --
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/9Rhyb8VlwbEJ.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/DSwL-wJMyToJ.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
> I would agree with not having a modify-body operation other than get/set. However, I do think that support for streaming responses is important in many situations so we should try to include it if possible (or maybe as an extended interface if people prefer). Passing in a callable or, in PHP 5.5, a generator (that could be fun) is the best way to handle large returns without blowing out your memory, so let's make sure that's supported.
Yes, support for streaming is very important. That's why I mentioned
Guzzle passes this responsibility off to an EntityBody object to
encapsulate the logic of streaming data onto or off of a data source.
An HTTP PSR could either do something similar (e.g. use an EntityBody
object) or account for various data types passed into the setBody()
method.
The easiest way to start that discussion would be to do the research on what the existing member projects do in that regard for their respective Request and Response objects. Those that commonly treat some header types as "special" are the ones to start with. Chris Wilkinson, are you up for adding that on to your workload?
I think we can get away without them *for now*. I think it would be enough to get started with an array of arrays for the header data structure, something like this:
$headers = [
'Header-Name-1' => [
['value'],
]
'Header-Name-2' => [
['value 1'],
['value 2'],
['value 3'],
]
];
Getting out headers would be an exercise in looping through both of them appropriately.
Thoughts?
Ideally: a HeaderCollection object that implements ArrayAccess. Headers
are accessed case-insensitively (as per spec) and each header is always
a string. To get at the raw array, add a getHeader($key) method that
always returns an array as per Paul's suggestion.
$headers = new HeaderCollection([
'Content-Type' => 'application/json';
]);
$headers->setHeader('Cache-Control', 'nocache');
$headers->setHeader('Content-Type', 'text/json');
Ahh but being perfectly compliant is one thing, assuming everyone else is, is another :)
Hi,There was a proposal to create a HTTP client interface earlier this year. As was noted at the time, the core HTTP message representation part (ie the request/response objects) is probably of more importance: it's used by both HTTP clients and frameworks.HTTP clients issue requests (through cURL for example) and return the response to the user. Some frameworks (eg Symfony) convert superglobals into a request object and let the user return a response object (which is then returned to the browser).It is actually possible to connect the two (eg for functional testing). Disparate objects, however, create problems (for example, the Symfony BrowserKit and HttpKernel components have their own Response classes - see https://github.com/symfony/symfony/issues/4475).Because of this, there should be a standard RequestInterface and ResponseInterface. The ClientInterface can then be developed separately, obviously making use of them.For reference, a non-exhaustive list of existing request/response object implementations:Symfony2 HttpFoundationhttps://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Request.php
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Response.phpSymfony2 BrowserKitGuzzleZend2BuzzRequestsAuraCakePHPI'd like to propose a Psr\Http package containing something along the lines of:interface MessageInterface{public function __toString();public function getStartLine();public function getProtocolVersion();public function setProtocolVersion($protocolVersion);public function getHeader($header);public function getHeaders();public function hasHeader($header);public function setHeader($header, $value);public function setHeaders(array $headers);public function addHeaders(array $headers);public function getBody();public function setBody($body);}interface RequestInterface extends MessageInterface{public function __construct($method, $url, $protocolVersion = '1.1');public function getResponse();public function setResponse(ResponseInterface $response);public function getMethod();public function setMethod($method);public function getUrl();public function setUrl($url);}interface ResponseInterface extends MessageInterface{public function __construct($statusCode, $reasonPhrase = null, $protocolVersion = '1.1');public function getRequest();public function setRequest(RequestInterface $request);public function getStatusCode();public function setStatusCode($statusCode);public function getReasonPhrase();public function setReasonPhrase($reasonPhrase);}This provides the basics for creating and interrogating request/response objects manually, and producing a HTTP message by casting it to a string.The headers aren't that easy to use though, as you have to set the entire value at once (and seeing what's been set is hard). Most existing implementations provide helper methods for some (if not most) of the headers as a result.So instead of:$response->setHeader('Cache-Control', 'private, max-age=3600, must-revalidate');You could do:$response->getCacheControlHeader()->setPrivate()->setMaxAge(3600)->setMustRevalidate();or even just:$response->setPrivate()->setMaxAge(3600)->setMustRevalidate();If these are added to the interfaces somehow, they should cover all standard headers (extensions can still be set manually). This does dramatically increase the complexity of implementation though (although you could just extend a provided abstract class, I can't really think of any need for variation), and has possibly extended the remit.Any thoughts?Chris (aka thewilkybarkid)