New HTTP client module

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

New HTTP client module

Shahar Evron-2
Hi,

Following my inability to implement the changes to Zend\Http\Client and friends on time, I've created a new module which includes my "branch" of the HTTP client (effectively it's almost a rewrite). Given that it's incompatible with the current implementation I don't see how it can make it to 2.0 but perhaps it will be ready for 2.1 or whatever the next BC-breaking release will be. In the mean time, I will continue to work on it as a separate module, and you are of course free to use it and help improving it.

Here is what's different:
- Most of the complex work is done by the transport layer, represented by Transport objects - these replace Adapters but also take on some responsibilities such as decoding transfer encodings and content encodings (chunked data, compressed data, etc). Right now a socket based transport object is provided (as well as a testing oriented mock transport object), but I plan to add curl and pecl_http ones.
- Request / response body is represented as "Entity" objects, which are transparent to the transport layer and request layers. Entity objects can be based on in-memory strings, files / streams (the default response entity for example uses PHP's php://temp stream to store data, thus avoiding potential memory blowouts), and even compose request data on the fly.
- All request related API was removed from the client (e.g. no $client->setUri() and such). The client can send responses, but does not have ZF1's request-like methods.
- Cookie management moved to CookieStore objects
- Clients now have a Headers object which allows setting client-global HTTP headers (such as the User-agent header), so there is no need to set them per request
- Client, request and response are less strict and more RFC compliant when it comes to accepting HTTP response codes, request method names, etc.

Here is what I still plan to add:
- More tests
- Documentation
- Events layer on both the client and transport objects
- HTTP Authentication through composable authentication handler objects (possibly will be done through an event interface)
- More transport objects
- Proxy support in existing transport objects (there will be no separate Proxy adapter)
- More entity objects (e.g. handle multipart/form-data requests)

There are probably some things I've forgotten, and the work is still very much in progress - in any case I encourage you to review and share feedback.

Shahar.
Reply | Threaded
Open this post in threaded view
|

Re: New HTTP client module

till


On Monday, August 13, 2012 at 9:57 PM, Shahar Evron wrote:

> Hi,
>
> Following my inability to implement the changes to Zend\Http\Client and friends on time, I've created a new module which includes my "branch" of the HTTP client (effectively it's almost a rewrite). Given that it's incompatible with the current implementation I don't see how it can make it to 2.0 but perhaps it will be ready for 2.1 or whatever the next BC-breaking release will be. In the mean time, I will continue to work on it as a separate module, and you are of course free to use it and help improving it.
>
> Here is what's different:
> - Most of the complex work is done by the transport layer, represented by Transport objects - these replace Adapters but also take on some responsibilities such as decoding transfer encodings and content encodings (chunked data, compressed data, etc). Right now a socket based transport object is provided (as well as a testing oriented mock transport object), but I plan to add curl and pecl_http ones.
> - Request / response body is represented as "Entity" objects, which are transparent to the transport layer and request layers. Entity objects can be based on in-memory strings, files / streams (the default response entity for example uses PHP's php://temp stream to store data, thus avoiding potential memory blowouts), and even compose request data on the fly.
> - All request related API was removed from the client (e.g. no $client->setUri() and such). The client can send responses, but does not have ZF1's request-like methods.
> - Cookie management moved to CookieStore objects
> - Clients now have a Headers object which allows setting client-global HTTP headers (such as the User-agent header), so there is no need to set them per request

Is this a good idea with testability, etc.?

> - Client, request and response are less strict and more RFC compliant when it comes to accepting HTTP response codes, request method names, etc.
>
> Here is what I still plan to add:
> - More tests
> - Documentation
> - Events layer on both the client and transport objects
> - HTTP Authentication through composable authentication handler objects (possibly will be done through an event interface)
> - More transport objects
> - Proxy support in existing transport objects (there will be no separate Proxy adapter)
> - More entity objects (e.g. handle multipart/form-data requests)
>
> There are probably some things I've forgotten, and the work is still very much in progress - in any case I encourage you to review and share feedback.
You didn't want to include a link? :) Not trolling, but please let me know where this is at.

Till
>
> Shahar.


Reply | Threaded
Open this post in threaded view
|

Re: New HTTP client module

Shahar Evron-2

On Mon, Aug 13, 2012 at 11:03 PM, till <[hidden email]> wrote:

> - Clients now have a Headers object which allows setting client-global HTTP headers (such as the User-agent header), so there is no need to set them per request

Is this a good idea with testability, etc.?

I'm not sure how this hinders testability. Can you elaborate?
 

You didn't want to include a link? :) Not trolling, but please let me know where this is at.


Definately forgot the link :) https://github.com/shevron/ZHttpClient2

Shahar.

Reply | Threaded
Open this post in threaded view
|

Re: New HTTP client module

till


On Monday, August 13, 2012 at 10:08 PM, Shahar Evron wrote:

>  
> On Mon, Aug 13, 2012 at 11:03 PM, till <[hidden email] (mailto:[hidden email])> wrote:
> >  
> > > - Clients now have a Headers object which allows setting client-global HTTP headers (such as the User-agent header), so there is no need to set them per request
> >  
> > Is this a good idea with testability, etc.?
>  
> I'm not sure how this hinders testability. Can you elaborate?
I have not looked at the code – do you mean the following:

$headers = new Headers(my headers);

And then injecting the $headers object into multiple client objects (for multiple requests)?

That looks good to me – for some reason it did sound like you had a static something hidden in there.  
>  
> >  
> > You didn't want to include a link? :) Not trolling, but please let me know where this is at.
>  
> Definately forgot the link :) https://github.com/shevron/ZHttpClient2
>  
> Shahar.  
Cool – will take a look.  

Thanks,
Till

Reply | Threaded
Open this post in threaded view
|

Re: New HTTP client module

Shahar Evron-2
In reply to this post by Shahar Evron-2
Another heads up: I've just pushed a new branch (https://github.com/shevron/ZHttpClient2/tree/feature/auth-handlers) which contains a preliminary implementation of Authentication providers - the idea is to have pluggable objects to handle HTTP authentication - at least support for basic and digest authentication, and possibly more providers in the future.

While the implementation is only preliminary (the digest one is not even supposed to work yet), I would be really happy if people can look into this and provide feedback / comments regarding the API and general direction.

Shahar.

On Mon, Aug 13, 2012 at 10:57 PM, Shahar Evron <[hidden email]> wrote:
Hi,

Following my inability to implement the changes to Zend\Http\Client and friends on time, I've created a new module which includes my "branch" of the HTTP client (effectively it's almost a rewrite). Given that it's incompatible with the current implementation I don't see how it can make it to 2.0 but perhaps it will be ready for 2.1 or whatever the next BC-breaking release will be. In the mean time, I will continue to work on it as a separate module, and you are of course free to use it and help improving it.

Here is what's different:
- Most of the complex work is done by the transport layer, represented by Transport objects - these replace Adapters but also take on some responsibilities such as decoding transfer encodings and content encodings (chunked data, compressed data, etc). Right now a socket based transport object is provided (as well as a testing oriented mock transport object), but I plan to add curl and pecl_http ones.
- Request / response body is represented as "Entity" objects, which are transparent to the transport layer and request layers. Entity objects can be based on in-memory strings, files / streams (the default response entity for example uses PHP's php://temp stream to store data, thus avoiding potential memory blowouts), and even compose request data on the fly.
- All request related API was removed from the client (e.g. no $client->setUri() and such). The client can send responses, but does not have ZF1's request-like methods.
- Cookie management moved to CookieStore objects
- Clients now have a Headers object which allows setting client-global HTTP headers (such as the User-agent header), so there is no need to set them per request
- Client, request and response are less strict and more RFC compliant when it comes to accepting HTTP response codes, request method names, etc.

Here is what I still plan to add:
- More tests
- Documentation
- Events layer on both the client and transport objects
- HTTP Authentication through composable authentication handler objects (possibly will be done through an event interface)
- More transport objects
- Proxy support in existing transport objects (there will be no separate Proxy adapter)
- More entity objects (e.g. handle multipart/form-data requests)

There are probably some things I've forgotten, and the work is still very much in progress - in any case I encourage you to review and share feedback.

Shahar.