Initial HTTP Client RFC now up

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

Initial HTTP Client RFC now up

Shahar Evron-2
Hi all,

For some time now I've been working on a partial rewrite of the HTTP client & related classes. Since my progress is pretty slow I've decided to post an RFC before I have a complete prototype, because I see a lot of other discussions going on and I think it makes sense to consolidate efforts.

This is high-level and initial, but I'd appreciate it if you can take a look at http://framework.zend.com/wiki/pages/viewpage.action?pageId=46793093 and post your comments.

A partial implementation, which I am updating from time to time, is at https://github.com/shevron/zf2/tree/feature/http-client-rewrite (this still contains some deprecated classes, which I will eventually remove when most of the transition is done).

Note that this doesn't include much reference to the Asynchronous HTTP Client discussion that is also going on. I wanted to first nail out the interface and general architecture of the HTTP stack before diving into more complex issues - I believe the async option could be added on top of this architecture without major conceptual changes. 

Feedback is much welcome.

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

Re: Initial HTTP Client RFC now up

Pádraic Brady
Hi Shahar,

The asynchronous discussion would be contingent on a final Zend/Http
architecture since it depends a lot on the architecture used. When
writing the prototype, the main problem I met was that Http\Client
contained far too much responsibility because it was designed to only
ever handle a single request before a reset. The result was that
Client stole responsibilities from requests and responses, so a lot of
what you put in the RFC looks really good!

Now, the idea for asynchronous support would never use Http\Client -
it would use a separate Client like class called Pool to manage the
different workflow. That is, in fact, the only new class needed if
your RFC is largely followed.

I would add a few more factors to include at some point:

1. A few open protocols like OAuth assume a HTTP Client conforming to
RFC 3982. This was not the case with Zend_Http_Client which required a
few hacks (eventually I just patched it a bit) because the underlying
PHP RFC compliance is pretty chaotic at times. That needs to be
included, at a minimum as an option, but preferably from Day 1 as its
default mode.
2. For some tasks, such as response handling, it would be really great
if these were available for reuse in a Utility class(es) somewhere for
non-Client based HTTP operations. Another protocol had me rewriting
chunks of Zend_Http_Client a while back to extract this and to make
requests/responses work better when used standalone. For that reason -
it may not be a terrible idea for requests/responses to handle their
specific tasks (not bury it in the transport layer where it's too
close to the adapters to be reusable).
3. Can we please ensure that secure connections are configured
consistently with peer verification enabled by default?
4. Please, no too-long methods ;).

Regards,
Paddy

On Sun, Feb 26, 2012 at 10:51 AM, Shahar Evron <[hidden email]> wrote:

> Hi all,
>
> For some time now I've been working on a partial rewrite of the HTTP client
> & related classes. Since my progress is pretty slow I've decided to post an
> RFC before I have a complete prototype, because I see a lot of other
> discussions going on and I think it makes sense to consolidate efforts.
>
> This is high-level and initial, but I'd appreciate it if you can take a look
> at http://framework.zend.com/wiki/pages/viewpage.action?pageId=46793093 and
> post your comments.
>
> A partial implementation, which I am updating from time to time, is at
> https://github.com/shevron/zf2/tree/feature/http-client-rewrite (this still
> contains some deprecated classes, which I will eventually remove when most
> of the transition is done).
>
> Note that this doesn't include much reference to the Asynchronous HTTP
> Client discussion that is also going on. I wanted to first nail out the
> interface and general architecture of the HTTP stack before diving into more
> complex issues - I believe the async option could be added on top of this
> architecture without major conceptual changes.
>
> Feedback is much welcome.
>
> Shahar.



--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Reply | Threaded
Open this post in threaded view
|

Re: Initial HTTP Client RFC now up

Pádraic Brady
Hi Shahar,

On Sun, Feb 26, 2012 at 6:41 PM, Shahar Evron <[hidden email]> wrote:

>> Now, the idea for asynchronous support would never use Http\Client -
>> it would use a separate Client like class called Pool to manage the
>> different workflow. That is, in fact, the only new class needed if
>> your RFC is largely followed.
>
>
> That's good. However why wouldn't the HTTP client (or a subclass of) be
> used? I can think of a lot of good things done by the HTTP client per my RFC
> that could be useful when sending request pools as well - handling cookies,
> redirections, auth etc. - is there any reason not to simply allow the HTTP
> client to send a pool of requests rather than a single request?
>
> BTW I was playing with the idea of adding event hooks to the HTTP layer -
> e.g. a hook for handling a finished request in a pool of requests. What do
> you think?

I'm not much of an EventManager user (have barely used it), but the
Async Pool prototype uses simple callbacks to great effect. Then
again, that is a prototype ;). There should be something even for
single requests - many recent clients will implement an
observer/listener. To be honest, I'm a bit wary of including
EventManager for too much outside the MVC stack since we now have
Closures which can serve similar purposes with one less dependency on
another super architecture. I'd prefer to keep it simple.

The reason for the new class, Pool, originally was because that was
the representation of a persistent Request Pool - vs a once-off
Multi-Request which is subtly different (the first is intended to
accept new requests on the move, the second is just a batch
processor). Batch processing is itself a synchronous unit of work - so
it's actually less efficient than a persistent pool.

Working it into the current client was near impossible. Also, both
classes shouldn't be mixed, in my opinion, because they don't
represent the same concept - you'll end up with a single class with
two discrete API sets - one for single requests, the other for a Pool,
and neither with a lot in common. Presumably we'll also have a third
API set of once-off requests (e.g. the current static API). The one
thing they would share are cookie handling etc., so maybe there's an
AbstractClient suggested? In my mind there are three classes: Browser
(simple once-offs - retains no state between requests), Client
(reusable for same host - more request options to set - retains state
until reset), and Pool (persistent socket management and rotation).

In any case, I'll closely track the Client with another slightly
improved Pool prototype once you're rolling ;). The important thing is
getting the Client ready - we can worry about a stable async option
after.

> I'm not sure I follow - RFC 3982? I am not familiar with that and looking it
> up resulted in something I am not sure how to relate to.

Sorry - should have been RFC 3986 ;). That's what I get writing emails
on a Sunday!

It concerns URI syntax. Main difference from PHP (not sure of PHP 5.4)
was the encoding of + in a URI. It throws off generating a correct
HMAC signature for a URI and POST data since languages may use older
RFCs which differed (i.e. PHP uses a few older RFCs) and created
inconsistent signatures.

>> 2. For some tasks, such as response handling, it would be really great
>> if these were available for reuse in a Utility class(es) somewhere for
>> non-Client based HTTP operations. Another protocol had me rewriting
>> chunks of Zend_Http_Client a while back to extract this and to make
>> requests/responses work better when used standalone. For that reason -
>> it may not be a terrible idea for requests/responses to handle their
>> specific tasks (not bury it in the transport layer where it's too
>> close to the adapters to be reusable).
>
>
> You mean things like breaking down a stream of bytes into headers, body etc.
> ? Can you give a concrete example?

For example, just decoding a response (gzip/chunked/enflate), or
generating a POST body from params, etc. In some cases, we can't do
this inside a client because we need to follow protocol specific steps
the client isn't aware of, or can't be made aware of easily. Though,
it's possible event hooks could allow for that given the right hooks
and accessible objects.

>> 3. Can we please ensure that secure connections are configured
>> consistently with peer verification enabled by default?
>
>
> Yes, absolutely. This must be done.
>
>>
>> 4. Please, no too-long methods ;).
>>
>
> Hmm.. can you give an example of a method you consider too long?

It's a small concern for monkey patching (did a lot of this for ZF1's
client so it was a small annoyance) and based on refactoring guidance
that advises against long method body's. Technically it doesn't change
design decisions in any way so don't worry about it. If you see a 100
line method broken into 3-4 smaller ones - that's the kind of thing I
mean. Requires less duplication where composition can't be applied and
monkey patching by inheritance is necessary.

Paddy
Reply | Threaded
Open this post in threaded view
|

Re: Initial HTTP Client RFC now up

Artur Bodera
On Sun, Feb 26, 2012 at 8:57 PM, Pádraic Brady <[hidden email]> wrote:
I'm not much of an EventManager user (have barely used it), but the
Async Pool prototype uses simple callbacks to great effect. Then
again, that is a prototype ;). There should be something even for
single requests - many recent clients will implement an
observer/listener. To be honest, I'm a bit wary of including
EventManager for too much outside the MVC stack since we now have
Closures which can serve similar purposes with one less dependency on
another super architecture. I'd prefer to keep it simple.

I'd like to invite you, Paddy, to take a look at it right now. It borrows many concepts from other languages and their respective frameworks. It allows you to implement observable objects (event-driven programming) and manage the trigger/response process in a controllable way.

Closures and lambdas are just a tool that's used together with Event Manager. 
Of course you could go all "caveman" and use just array_pop() + lambdas, but you'll quickly get yourself into a corner.


The Zend\EventManager itself is very simple and lightweight. 
It does the job and is very easy to use.

Personally, I've been playing with event-programming concepts for a few years now, and I stayed away from MVC. I'd almost risk the statement that we could rebuild current MVC without EM. Places where EM _really_ shines are those (extendable) components that are lightweight but expose event bus you can tap into -- allowing you to wire logic or change behaviors without rewriting (extending) the whole thing. HTTP Client is a perfect example of such use-case.

Matthew wrote a good piece of code that is universal and lightweight enough to use it throughout the whole framework (and to make me consider it, which is an achievement ;))). It'd be a shame if HTTP Client (or part thereof) implemented the same paradigm, but using it's own, competing routines.

Have a splendid day.


A.


-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: Initial HTTP Client RFC now up

weierophinney
Administrator
In reply to this post by Pádraic Brady
-- Pádraic Brady <[hidden email]> wrote
(on Sunday, 26 February 2012, 07:57 PM +0000):

> On Sun, Feb 26, 2012 at 6:41 PM, Shahar Evron <[hidden email]> wrote:
> >> Now, the idea for asynchronous support would never use Http\Client -
> >> it would use a separate Client like class called Pool to manage the
> >> different workflow. That is, in fact, the only new class needed if
> >> your RFC is largely followed.
> >
> >
> > That's good. However why wouldn't the HTTP client (or a subclass of) be
> > used? I can think of a lot of good things done by the HTTP client per my RFC
> > that could be useful when sending request pools as well - handling cookies,
> > redirections, auth etc. - is there any reason not to simply allow the HTTP
> > client to send a pool of requests rather than a single request?
> >
> > BTW I was playing with the idea of adding event hooks to the HTTP layer -
> > e.g. a hook for handling a finished request in a pool of requests. What do
> > you think?
>
> I'm not much of an EventManager user (have barely used it), but the
> Async Pool prototype uses simple callbacks to great effect. Then
> again, that is a prototype ;). There should be something even for
> single requests - many recent clients will implement an
> observer/listener. To be honest, I'm a bit wary of including
> EventManager for too much outside the MVC stack since we now have
> Closures which can serve similar purposes with one less dependency on
> another super architecture. I'd prefer to keep it simple.

I'm going to argue against NOT using the EM. The reason being that we
should be moving towards _more_ consistency in the framework, not less.
Having a different "hook" system for the HTTP client would go against
this. Also, in terms of learnability, using the same interface for
attaching these hooks as you have everywhere else will make it easier to
explain to users.

Additionally, the EM provides some benefits that I think the client
and/or Async Pool could utilize -- things like prioritized callbacks,
short circuiting, etc. Additionally, the EM is actually quite fast --
looking through Evan's spreadsheet, its various calls don't really even
show up.


--
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
Reply | Threaded
Open this post in threaded view
|

Re: Initial HTTP Client RFC now up

Wil Moore III
> observer/listener. To be honest, I'm a bit wary of including
> EventManager for too much outside the MVC stack since we now have
> Closures which can serve similar purposes with one less dependency on
> another super architecture. I'd prefer to keep it simple.

I am 100% on-board with decoupling as many things in ZF2 as possible; however, if there is one component that should be used wherever possible, I believe it is the EventManager component. Anyone that hasn't taken a really close look at it yet, really should take the time to learn it inside and out. It's obviously not hard to believe that it is my favorite component of the entire stack.

--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|

Re: Initial HTTP Client RFC now up

Pádraic Brady
In reply to this post by Artur Bodera
On Mon, Feb 27, 2012 at 12:12 PM, Artur Bodera <[hidden email]> wrote:
> Closures and lambdas are just a tool that's used together with Event
> Manager.
> Of course you could go all "caveman" and use just array_pop() + lambdas, but
> you'll quickly get yourself into a corner.

I'm finding it's quite a happy corner out here with all the other
cavemen. That might have something to do with the fact that the Async
prototype's API is complete and it hasn't bugged out yet.

> Personally, I've been playing with event-programming concepts for a few
> years now, and I stayed away from MVC. I'd almost risk the statement that we
> could rebuild current MVC without EM. Places where EM _really_ shines are
> those (extendable) components that are lightweight but expose event bus you
> can tap into -- allowing you to wire logic or change behaviors without
> rewriting (extending) the whole thing. HTTP Client is a perfect example of
> such use-case.

It's a HTTP Client. A general purpose library whose internal
operations are defined by the HTTP specs and various RFCs. The only
behaviours to change are what goes in, and what you do when something
comes out.

> Matthew wrote a good piece of code that is universal and lightweight enough
> to use it throughout the whole framework (and to make me consider it, which
> is an achievement ;))). It'd be a shame if HTTP Client (or part thereof)
> implemented the same paradigm, but using it's own, competing routines.

You mean the competing routine of having a request execute a callback?
There is no routine or competing architecture here - it just executes
the provided callback. I thought that was the whole point of having
anonymous functions in the first place for PHP?

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Reply | Threaded
Open this post in threaded view
|

Re: Initial HTTP Client RFC now up

Artur Bodera
On Mon, Feb 27, 2012 at 8:06 PM, Pádraic Brady <[hidden email]> wrote:
I'm finding it's quite a happy corner out here with all the other
cavemen. That might have something to do with the fact that the Async
prototype's API is complete and it hasn't bugged out yet.

It's not about that ;-)

btw: remember "Prehistoric" game ? 


It's a HTTP Client. A general purpose library whose internal
operations are defined by the HTTP specs and various RFCs. The only
behaviours to change are what goes in, and what you do when something
comes out.

That's exactly why it should delegate callback handling to EventManager, SOC.
 

You mean the competing routine of having a request execute a callback?
There is no routine or competing architecture here - it just executes
the provided callback. I thought that was the whole point of having
anonymous functions in the first place for PHP?

What If I wanted to execute 2 callbacks? 

What If I wanted to remove one of those callbacks, because a concurrent connection failed (or deprecated the first).

What If I wanted to have 3 callbacks that will execute in sequence, but one of them can start subsequent connections, attach additional callbacks and/or short-circuit that operation (for whatever reason).

What If I wanted to attach another callback _at top_ of the stack, so it executes first (i.e. validating the http response body) ?

What If I wanted to have an added, permutable context injected  into (available in) listeners? (not only use($foo) lambda-style)



Just a few from the top of my head. If you used EM, you don't worry about those at all, and you _still_ can provide the very same API as you have now.


A.
-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]




 
Reply | Threaded
Open this post in threaded view
|

Re: Initial HTTP Client RFC now up

Pádraic Brady
In reply to this post by weierophinney
On Mon, Feb 27, 2012 at 2:44 PM, Matthew Weier O'Phinney
<[hidden email]> wrote:
> I'm going to argue against NOT using the EM. The reason being that we
> should be moving towards _more_ consistency in the framework, not less.
> Having a different "hook" system for the HTTP client would go against
> this. Also, in terms of learnability, using the same interface for
> attaching these hooks as you have everywhere else will make it easier to
> explain to users.

How about more consistency in PHP and not less. It's the same
argument. We have a unit of logic which can be passed along for a
"complete" state represented by a basic PHP closure. That's learning
gone - it's basic PHP. Closures/callbacks are already well understood
and used in PHP. There goes consistency. What remains is the question
of what an EventManager would add above and beyond PHP basics. Before
my prototype that barely works is sandblasted into the ground because
I dared to use caveman style closures... ;).

> Additionally, the EM provides some benefits that I think the client
> and/or Async Pool could utilize -- things like prioritized callbacks,
> short circuiting, etc. Additionally, the EM is actually quite fast --
> looking through Evan's spreadsheet, its various calls don't really even
> show up.

To be honest, I just don't see the use case for it. Responses tend to
be dealt with in a fairly serialised fashion. I have no doubt you
could massage the handling into an event style with prioritised events
and short circuiting - thing is, just thinking about that makes me
want to refactor it already before it blows my mind and contaminates
the classes I already use for these purposes. What would the existing
prototype's API look like with EventManager in use? I've already said
I'm not super familiar with it to start with so take pity on a newbie
;).

My main worry here is that someone will announce we need to create
EventManager stuff outside of the client. I'm more than happy to do
that for MVC workflows - but hands off my Model layer. If the
framework has issues using plain old PHP classes and closures, and
demands too many new classes to bridge the gap, it can go jump in a
lake.

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Reply | Threaded
Open this post in threaded view
|

Re: Initial HTTP Client RFC now up

Pádraic Brady
In reply to this post by Artur Bodera
On Mon, Feb 27, 2012 at 7:28 PM, Artur Bodera <[hidden email]> wrote:
> On Mon, Feb 27, 2012 at 8:06 PM, Pádraic Brady <[hidden email]>
> wrote:
>>
>> I'm finding it's quite a happy corner out here with all the other
>> cavemen. That might have something to do with the fact that the Async
>> prototype's API is complete and it hasn't bugged out yet.
>
>
> It's not about that ;-)

Arguably, it is. Nobody has given a concrete reason as to why
EventManager would be needed. Ergo, the current design is sufficient
and doesn't need any form of refactoring (a reminder it's a prototype
so that's complete changeable! :P).

> btw: remember "Prehistoric" game ?

Sure. My brother still has a sore head from... You meant the other
game, I think? ;)

>> It's a HTTP Client. A general purpose library whose internal
>> operations are defined by the HTTP specs and various RFCs. The only
>> behaviours to change are what goes in, and what you do when something
>> comes out.
>
> That's exactly why it should delegate callback handling to EventManager,
> SOC.

That's exactly what the current closure does too - what's the difference?

>> You mean the competing routine of having a request execute a callback?
>> There is no routine or competing architecture here - it just executes
>> the provided callback. I thought that was the whole point of having
>> anonymous functions in the first place for PHP?
>
> What If I wanted to execute 2 callbacks?

It's a callback. Use a class and move on.

> What If I wanted to remove one of those callbacks, because a concurrent
> connection failed (or deprecated the first).

Don't execute them? Why would you remove them? (Bear in mind this is a
generic Pool - each Request has a distinct callback anyway)

> What If I wanted to have 3 callbacks that will execute in sequence, but one
> of them can start subsequent connections, attach additional callbacks and/or
> short-circuit that operation (for whatever reason).

Use a class.

> What If I wanted to attach another callback _at top_ of the stack, so it
> executes first (i.e. validating the http response body) ?

Use a class.

> What If I wanted to have an added, permutable context injected  into
> (available in) listeners? (not only use($foo) lambda-style)

Example?

> Just a few from the top of my head. If you used EM, you don't worry about
> those at all, and you _still_ can provide the very same API as you have now.

I pretty much asked why you need a stack of prioritised callbacks. I
can't be convinced unless there's some specific need I could bother
writing a unit test for should the prototype move towards being
developed into something useful.

As a tip, I write a lot of protocol stacks - I never needed
prioritised callbacks before. All the protocol logic tends to be a
massively predictable set of logic sequences.

We need actual use cases to provoke change! Otherwise it's just
another round of pointless overengineering for the sake of it.

Paddy


--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Reply | Threaded
Open this post in threaded view
|

Re: Initial HTTP Client RFC now up

till-2
In reply to this post by Shahar Evron-2
On Wed, Feb 29, 2012 at 6:34 PM, Shahar Evron <[hidden email]> wrote:

> Hi,
>
> On Tue, Feb 28, 2012 at 4:58 PM, till <[hidden email]> wrote:
>>
>>
>>
>> On Sun, Feb 26, 2012 at 11:51 AM, Shahar Evron <[hidden email]>
>> wrote:
>>>
>>> Hi all,
>>>
>>> For some time now I've been working on a partial rewrite of the HTTP
>>> client & related classes. Since my progress is pretty slow I've decided to
>>> post an RFC before I have a complete prototype, because I see a lot of other
>>> discussions going on and I think it makes sense to consolidate efforts.
>>>
>>> This is high-level and initial, but I'd appreciate it if you can take a
>>> look at http://framework.zend.com/wiki/pages/viewpage.action?pageId=46793093
>>> and post your comments.
>>>
>>> A partial implementation, which I am updating from time to time, is at
>>> https://github.com/shevron/zf2/tree/feature/http-client-rewrite (this still
>>> contains some deprecated classes, which I will eventually remove when most
>>> of the transition is done).
>>
>>
>> I looked at it briefly – lot of abstraction.
>>
>> I see ClientStatic which contains part of a DSL. But I'm puzzled why it
>> had to be static.
>>
>
> Actually I didn't write that one - it's in the code I inherited and am
> planning to remove.

Ah weird. Can you clarify which is which?

>> For a complete DSL, I'd like all methods to be implemented (in a
>> non-static object):
>>
>> $client->copy();
>> $client->delete();
>> $client->get();
>> $client->head()
>> $client->post($data);
>> $client->put($data);
>>
>> etc. pp..
>
>
> I am completely with you on this one - that was my plan :)

I haven't give up hope:
http://framework.zend.com/issues/browse/ZF-5875

>>
>> I briefly looked through the classes – btw, kudos for unit tests, they are
>> pretty helpful.
>>
>
> Yes, I am particularly proud of those :)
>
>>
>> When I looked into prepare request – shouldn't it be able to replace
>> headers or merge headers?
>
>
> How do you mean? If you are referring to merging / replacing the "global"
> headers (the headers set in the client, I don't have a better name for them)
> into headers set in the request, then yes - it should. I am a bit unhappy
> with how Zend\Http\Header was done, and am thinking about doing slight
> changes there as well. It is not easy to know which headers should be
> appended, which should be replaced, etc.
>
> If this was not what you meant than I'd appreciate it if you elaborate.

It looked like I couldn't overwrite headers.

Also, what's the reason for all the abstraction in the headers? It
looks like most classes contain duplicate code anyway.

>> I'm not sure if I like all the abstraction in form that I have to create a
>> request object and a client object and inject one into the other. That seems
>> very Java-like. I can see why flexibility is great (especially to test this
>> implementations) but IMHO it requires too much code to be written again and
>> again.
>>
>>
>> I could probably live with that with a DSL wrapping around it.
>>
>
> For simple requests, I think that:
>
> $client = new Client();
> $respone = $client->get('http://www.example.com/...');
>
> Is simple enough. No?
>
> For anything more complex, I don't think that instantiating a request would
> be much more overhead.

Care to share a more advanced example? Just so I can wrap my head around it.

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

Re: Initial HTTP Client RFC now up

weierophinney
Administrator
-- till <[hidden email]> wrote
(on Wednesday, 29 February 2012, 07:51 PM +0100):

> On Wed, Feb 29, 2012 at 6:34 PM, Shahar Evron <[hidden email]> wrote:
> > On Tue, Feb 28, 2012 at 4:58 PM, till <[hidden email]> wrote:
> > > On Sun, Feb 26, 2012 at 11:51 AM, Shahar Evron <[hidden email]>
> > > wrote:
> > How do you mean? If you are referring to merging / replacing the "global"
> > headers (the headers set in the client, I don't have a better name for them)
> > into headers set in the request, then yes - it should. I am a bit unhappy
> > with how Zend\Http\Header was done, and am thinking about doing slight
> > changes there as well. It is not easy to know which headers should be
> > appended, which should be replaced, etc.
> >
> > If this was not what you meant than I'd appreciate it if you elaborate.
>
> It looked like I couldn't overwrite headers.
>
> Also, what's the reason for all the abstraction in the headers? It
> looks like most classes contain duplicate code anyway.

Because it allows us to do things like this:

    https://github.com/zendframework/zf2/pull/859/files

which then allows us to do things like:

    $accept = $headers->get('accept');
    foreach ($accept->getPrioritized() as $type) {
        switch ($type) {
            case 'application/json':
                break;
            case 'application/atom+xml':
                break;
        }
    }

which is a lot simpler than parsing the header value yourself and trying
to figure out the q priority. :)

One note: header objects are not created unless _requested_, so a lot of
that abstraction will never even be seen by the developer unless used.

Another note: this is one component/subcomponent where using traits
would be really nice, for exactly the code duplication issues you raise.
:)

--
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