HTPP stack changes

[DeNix]

Hi all,
As a followup to previous URI/Request discussion I propose few changes
to HTTP stack
I decided to discuss it here first before submitting PRs

Changes are:

-- add Stdlib\Parameters object to Zend\Uri to represet query parameters

-- bridge Http\Request::query() and Uri:query(), or most probably
request query() should just proxy to Uri
    (query is actually a property of URI)

-- add Http\Header\VersionAwareInterface with set/getVersion() methods
for all headers that have version dependent behaviour

-- add Http\AbstractMessage (implements Stdlib\MessageInterface) with
all common headers/body methods
    and make Http\Request/Response extend it

-- remove envParams and serverParams  from Http\Request
    Those are not HTTP standard properies and Mvc stack uses
Http\PhpEnvironment\Request anyway

I can also work on adding HTTP standard Http\Entity to Request/Response.
But this needs Shahar's approval as he have most of the job already done.

All the above doesn't change API but internal design.
Let me know what do you think.

Denis

[weierophinney]

-- Denis Portnov <[hidden email]> wrote
(on Friday, 15 June 2012, 03:08 AM +0400):
> As a followup to previous URI/Request discussion I propose few
> changes to HTTP stack
> I decided to discuss it here first before submitting PRs

Sounds good to me!

> Changes are:
>
> -- add Stdlib\Parameters object to Zend\Uri to represet query parameters
>
> -- bridge Http\Request::query() and Uri:query(), or most probably
> request query() should just proxy to Uri
>    (query is actually a property of URI)
>
> -- add Http\Header\VersionAwareInterface with set/getVersion()
> methods for all headers that have version dependent behaviour
>
> -- add Http\AbstractMessage (implements Stdlib\MessageInterface)
> with all common headers/body methods
>    and make Http\Request/Response extend it
>
> -- remove envParams and serverParams  from Http\Request
>    Those are not HTTP standard properies and Mvc stack uses
> Http\PhpEnvironment\Request anyway
>
> I can also work on adding HTTP standard Http\Entity to
> Request/Response. But this needs Shahar's approval as he have most
> of the job already done.
>
> All the above doesn't change API but internal design.
> Let me know what do you think.
>
> Denis
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[Shahar Evron-2]

Hi,

This sounds very good. Feel free to grab anything from what I've already done, but be aware that it's not 100% complete, some of it is proof-of-concept grade. I'd love to work with you on this, unfortunately I have been very unresponsive in the last few months (sorry all...) maybe it's best you take over. I will do my best to provide feedback and patches.

In my branch there are some additional changes which I believe should be pulled in eventually:
 - Reduced strictness of HTTP method and response code checking (the RFC is way more permissive than the current implementation)
 - HTTP DSL methods in Http\Client: get(), post(), put(), delete()
 - Addition of CookieStore to Http\Client
 - Addition of Client-level headers (e.g. headers like Accept, User-Agent etc. can have Client-wide defaults set rather than per request)
 - Entity implementation (the most complex and least proven one is how form data set in post() plays with the Entity object)
 - Options are provided as ClientOptions, TransportOptions etc. objects rather than arrays
 - Transport layer fixes and improvements

I'll do my best to spend more time on IRC this week so we can discuss things and I can help.

Shahar.

On Fri, Jun 15, 2012 at 4:59 PM, Matthew Weier O'Phinney <[hidden email]> wrote:

-- Denis Portnov <[hidden email]> wrote
(on Friday, 15 June 2012, 03:08 AM +0400):

> As a followup to previous URI/Request discussion I propose few
> changes to HTTP stack
> I decided to discuss it here first before submitting PRs

Sounds good to me!

> Changes are:
>
> -- add Stdlib\Parameters object to Zend\Uri to represet query parameters
>
> -- bridge Http\Request::query() and Uri:query(), or most probably
> request query() should just proxy to Uri
>    (query is actually a property of URI)
>
> -- add Http\Header\VersionAwareInterface with set/getVersion()
> methods for all headers that have version dependent behaviour
>
> -- add Http\AbstractMessage (implements Stdlib\MessageInterface)
> with all common headers/body methods
>    and make Http\Request/Response extend it
>
> -- remove envParams and serverParams  from Http\Request
>    Those are not HTTP standard properies and Mvc stack uses
> Http\PhpEnvironment\Request anyway
>
> I can also work on adding HTTP standard Http\Entity to
> Request/Response. But this needs Shahar's approval as he have most
> of the job already done.
>
> All the above doesn't change API but internal design.
> Let me know what do you think.
>
> Denis
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[DeNix]

Hi Shahar,

On 16.06.2012 21:59, Shahar Evron wrote:
> Hi,
>
> This sounds very good. Feel free to grab anything from what I've
> already done, but be aware that it's not 100% complete, some of it is
> proof-of-concept grade. I'd love to work with you on this,
> unfortunately I have been very unresponsive in the last few months
> (sorry all...) maybe it's best you take over. I will do my best to
> provide feedback and patches.
Great, thanks. I'll grab your code, go in small steps and expose my work
as [WIP ] PR so you and everyone could review
>
>  - Addition of CookieStore to Http\Client

What if we just implement Cookie/Cookies analogus to Header/Headers ?

>  - Entity implementation (the most complex and least proven one is how
> form data set in post() plays with the Entity object)

Still grabbin my head around entities, should be fairly complex to
handle multiple files upload and at the same time keep request/resonse
lightweight

>  - Options are provided as ClientOptions, TransportOptions etc.
> objects rather than arrays
>  - Transport layer fixes and improvements
>
> I'll do my best to spend more time on IRC this week so we can discuss
> things and I can help.
>
Thanks
Denis

[Shahar Evron-2]

Hi,

On Sun, Jun 17, 2012 at 1:24 AM, Denis Portnov <[hidden email]> wrote:

Hi Shahar,

On 16.06.2012 21:59, Shahar Evron wrote:

Hi,

This sounds very good. Feel free to grab anything from what I've already done, but be aware that it's not 100% complete, some of it is proof-of-concept grade. I'd love to work with you on this, unfortunately I have been very unresponsive in the last few months (sorry all...) maybe it's best you take over. I will do my best to provide feedback and patches.

Great, thanks. I'll grab your code, go in small steps and expose my work as [WIP ] PR so you and everyone could review

 - Addition of CookieStore to Http\Client

What if we just implement Cookie/Cookies analogus to Header/Headers ?

It's not exactly analogous. The idea is to have an abstract CookieStore object which both stores cookies and implements the policiy of which cookies to send in each request. So far my implementation only includes a based in-memory Cookie store, but I do see potential for DB or cookie file based storage.
 

 - Entity implementation (the most complex and least proven one is how form data set in post() plays with the Entity object)

Still grabbin my head around entities, should be fairly complex to handle multiple files upload and at the same time keep request/resonse lightweight

I don't think it will be very complex - the way Entity objects are sent / received (in chunks by the transport layer) actually allows us to use open stream resources when "sending" a single or multiple file uploads request instead of reading it all to memory, which means it will be much more lightweight. Implementation wise I don't think it will be too difficult, and I can try to give it a go in the next few days. The important think is to ensure the Entity concept works as least as good as what the current HTTP client provides, and move on from there.
 
Shahar.

 

 - Options are provided as ClientOptions, TransportOptions etc. objects rather than arreays
 - Transport layer fixes and improvements

I'll do my best to spend more time on IRC this week so we can discuss things and I can help.

Thanks
Denis

[DeNix]

On 17.06.2012 9:05, Shahar Evron wrote:

 - Addition of CookieStore to Http\Client

What if we just implement Cookie/Cookies analogus to Header/Headers ?

It's not exactly analogous. The idea is to have an abstract CookieStore object which both stores cookies and implements the policiy of which cookies to send in each request. So far my implementation only includes a based in-memory Cookie store, but I do see potential for DB or cookie file based storage.

Yes I was not correct. What I ment is to have a separate Cookie calss representing cookie name/value and attributes, then Cookies as collection of cookie objects
and yes, then cookie store as an cookie object storage, with ability to retrieve by URI, request etc and various storage adapters

 

 - Entity implementation (the most complex and least proven one is how form data set in post() plays with the Entity object)

Still grabbin my head around entities, should be fairly complex to handle multiple files upload and at the same time keep request/resonse lightweight

I don't think it will be very complex - the way Entity objects are sent / received (in chunks by the transport layer) actually allows us to use open stream resources when "sending" a single or multiple file uploads request instead of reading it all to memory, which means it will be much more lightweight. Implementation wise I don't think it will be too difficult, and I can try to give it a go in the next few days. The important think is to ensure the Entity concept works as least as good as what the current HTTP client provides, and move on from there.

SHould there be EntityInterface compatuble with RC definition i.e have methods getContentType(), getContentLength(). getContentEncoding() ?

 
Shahar.

 

Btw, If you have few mins, here is my PR that extends URI with queryParameters and modifies Request::query() to proxy to Uri::query()

Denis