Zend_Http_Request - do we have a naming conflict?

[Shahar Evron]

Hi Guys,

We have been talking about sharing components between Zend_Http_Client
and Zend_Http_Server, and creating a Zend_Http_Request class based on
similar concepts of the Zend_Http_Response class.

In the mean time, Matthew started writing another Zend_Http_Request for
the MVC component.

Since as far as I understand these are two different classes, I think we
need to decide the correct naming for each one.

In my opinion, since the MVC Zend_Http_Request is more about the request
then the HTTP - I think it should be renamed Zend_Request_Http -
especially as it inherits from Zend_Request_Interface.

Generally speaking I think it should be closer to the MVC (controller?)
namespace then on the Http namespace.

Of course, these are just my thoughts and I'm biased ;)

What do you guys think?

Shahar.

[Mat Scales]

Similar bias, but I agree that it doesn't belong inside Zend_Http.

Shahar Evron wrote:

> Hi Guys,
>
> We have been talking about sharing components between Zend_Http_Client
> and Zend_Http_Server, and creating a Zend_Http_Request class based on
> similar concepts of the Zend_Http_Response class.
>
> In the mean time, Matthew started writing another Zend_Http_Request for
> the MVC component.
>
> Since as far as I understand these are two different classes, I think we
> need to decide the correct naming for each one.
>
> In my opinion, since the MVC Zend_Http_Request is more about the request
> then the HTTP - I think it should be renamed Zend_Request_Http -
> especially as it inherits from Zend_Request_Interface.
>
> Generally speaking I think it should be closer to the MVC (controller?)
> namespace then on the Http namespace.
>
> Of course, these are just my thoughts and I'm biased ;)
>
> What do you guys think?
>
> Shahar.
>  

[weierophinney]

Cross posting, as this affects the MVC components.

-- Shahar Evron <[hidden email]> wrote
(on Thursday, 26 October 2006, 10:20 AM +0200):

> We have been talking about sharing components between Zend_Http_Client
> and Zend_Http_Server, and creating a Zend_Http_Request class based on
> similar concepts of the Zend_Http_Response class.
>
> In the mean time, Matthew started writing another Zend_Http_Request for
> the MVC component.
>
> Since as far as I understand these are two different classes, I think we
> need to decide the correct naming for each one.
>
> In my opinion, since the MVC Zend_Http_Request is more about the request
> then the HTTP - I think it should be renamed Zend_Request_Http -
> especially as it inherits from Zend_Request_Interface.

The decisioning made regarding the requests was thus:
   
    * Create a generic request interface (Zend_Request_Interface)
    * Have request implementations be located with the
      protocol/environment they support (Zend_Http_Request,
      Zend_Cli_Request, Zend_Controller_Request_*)

Zend_Http_Request was chosen as a name for several reasons:

    * It contains accessors for the various elements present in an HTTP
      request as expected by PHP: _GET, _POST, and _COOKIE, as well as
      _SESSION (which, while not strictly HTTP, in PHP typically only
      makes sense in PHP).
    * It contains accessors that deal with the request URI --
      specifically, REQUEST_URI and PATH_INFO.

What it does *not* have is information on routing or any information
pertaining to the controller or action requested in a front controller
environment. It is for this reason that we (there were several of us
from the MVC team involved in its creation) originally named it
Zend_Http_Request; it has little to do with the controller and more to
do with the HTTP environment.

(In fact, Zend_Controller has it's own request interface, and
Zend_Controller_Request_Http extends that and proxies to
Zend_Http_Request to obtain the rest of its own environment.)

What I'm wondering is how the HTTP request class you need for the HTTP
client and server differs from the implementation we've done, and if
there's any overlap. If they serve very different purposes, I'd be happy
to rename or even incorporate our Zend_Http_Request into
Zend_Controller_Request_Http, but we'd need to do so in the next day or
so before the 0.2 code freeze.

--
Matthew Weier O'Phinney
PHP Developer            | [hidden email]
Zend - The PHP Company   | http://www.zend.com/

[Shahar Evron]

Hi,

Matthew Weier O'Phinney wrote:
> What I'm wondering is how the HTTP request class you need for the HTTP
> client and server differs from the implementation we've done, and if
> there's any overlap. If they serve very different purposes, I'd be happy
> to rename or even incorporate our Zend_Http_Request into
> Zend_Controller_Request_Http, but we'd need to do so in the next day or
> so before the 0.2 code freeze.

It would be worth to see if were actually talking about the same thing.
While we don't have Zend_Http_Request planned out yes, this is more or
less what we have in mind:

* Extends Zend_Http_Message which is a container and parser for the
common parts of all HTTP messages (namely body and headers)

* A Container and access methods for these variables:
  * Request HTTP headers (and each header individually)
  * Request body (if any - in POST requests, etc.)
  * The request first line (method, URI, HTTP version)
  * Easy access to GET / POST / Cookie parameters
  * Easy access to files and RAW post data

* Static "parser" functions that take a plain-text HTTP request (as read
by the server for example) and extract the different parts out of it,
and a factory method that instanciates a new Request object from such
string.

* asString method that makes a HTTP request string out of the object.
This string can be sent by the client to the server over a TCP connection.
       
* The general idea is that if you read (as a server) an HTTP request
from an open TCP connection, you could do this:
<?php
  // $req_str is the full request as it was read from the socket
  $request = Zend_Http_Request::factory($req_str);

  // This should be true:
  ($request->asString() == $req_str);
?>

All in all, it sounds like we have a common basis here (the container
for request parameters and cookies), but our idea of Zend_Http_Request
 is fatter, and contains allot of things the MVC does not need - like
the string parsing methods, the asString() method, and possibly the need
to keep the entire request as string.

Do you see any architecture that will fit the needs of both the
Zend_Http_Server / Client and the MVC modules?


Shahar.

[Mat Scales]

Matthew Weier O'Phinney wrote:
> What I'm wondering is how the HTTP request class you need for the HTTP
> client and server differs from the implementation we've done, and if
> there's any overlap. If they serve very different purposes, I'd be happy
> to rename or even incorporate our Zend_Http_Request into
> Zend_Controller_Request_Http, but we'd need to do so in the next day or
> so before the 0.2 code freeze
For the server implementation, the request class needs to represent a
generic incoming HTTP request.  So when calling $request->getQuery(
'foo' ), I need it to look at it's own internal representation of the
query string and tell me the value of the parameter - $_GET is never
even set in a CLI environment and can only represent one request at a
time.  In fact, I want to be able to pull out the query parameters so
that I can build $_GET myself, so that it is available to user scripts.  
The same applies to $_POST, $_FILES and $_COOKIES.

I also need a method to parse a HTTP request, e.g.:

GET /login.php HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.8)
Gecko/20061025 Firefox/1.5.0.8
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=tb21ao9qgrllt97btg9u6q0521
Cache-Control: max-age=0


and set these internal variables.

Having looked at the functionality currently in the incubator
Zend_Http_Request, it seems like there is not enough common
functionality for them to be the same class.  Merging the two classes
would probably make the resulting class bloated and unwieldy for either
purpose.