New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Similar functionality to Zend_Http #313

Closed
qiangxue opened this Issue Feb 15, 2012 · 34 comments

Comments

Projects
None yet
6 participants
@qiangxue
Member

qiangxue commented Feb 15, 2012

Is there anything on the features list that will resemble the usage of
Zend_Http client and adapters?

Migrated from http://code.google.com/p/yii/issues/detail?id=1085


earlier comments

nick.shelomanov said, at 2011-01-09T03:39:24.000Z:

It wouldn't appear that there is much point in re-implementing what has already been implemented in Zend_Http as that component can be used from the Zend framework. However, if such a component is implemented it would be VERY helpful if it could offer curl_multi functionality to enable multithreading.

mitallast said, at 2011-02-03T19:10:15.000Z:

Php has extension written in C, using libcurl. I use it in production. I'm sure it's don't need to invent a new bike. http://www.php.net/manual/en/book.http.php

joeblocher said, at 2011-06-17T10:18:15.000Z:

See http://www.yiiframework.com/extension/ehttpclient

intel352 said, at 2011-06-26T18:45:11.000Z:

That C extension is a PECL extension. Instead we need a solution that will benefit framework users that are in a shared hosting environment without the ability to install PECL extensions.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Feb 21, 2012

Member

why not use Zend_Http? Yii plays well together with Zend, there is also an autoloader extension for Zend Classes.

Member

cebe commented Feb 21, 2012

why not use Zend_Http? Yii plays well together with Zend, there is also an autoloader extension for Zend Classes.

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Apr 27, 2012

Contributor

Just a thought: @phpnode already wrote up a response class. What if a complete http stack would be implemented for Yii? There would be little left for a CHttpClient that's similar to what Zend_Http_Client is doing. That could wrap around pecl::http and fall back to userland PHP.

Contributor

DaSourcerer commented Apr 27, 2012

Just a thought: @phpnode already wrote up a response class. What if a complete http stack would be implemented for Yii? There would be little left for a CHttpClient that's similar to what Zend_Http_Client is doing. That could wrap around pecl::http and fall back to userland PHP.

DaSourcerer added a commit to DaSourcerer/yii that referenced this issue Jul 22, 2012

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Sep 5, 2012

Contributor

I'm currently working on an implementation that works entirely with streams. It would be interesting to hear your opinion on this.

Contributor

DaSourcerer commented Sep 5, 2012

I'm currently working on an implementation that works entirely with streams. It would be interesting to hear your opinion on this.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Sep 7, 2012

Member

Good naming.

Member

samdark commented Sep 7, 2012

Good naming.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Sep 7, 2012

Member

User agent should be changeable.

Member

samdark commented Sep 7, 2012

User agent should be changeable.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Sep 7, 2012

Member

Looks good to me except some thongs like "information purpose" params.

Member

samdark commented Sep 7, 2012

Looks good to me except some thongs like "information purpose" params.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Sep 7, 2012

Member

I think it will be good to have it in 1.1.

Member

samdark commented Sep 7, 2012

I think it will be good to have it in 1.1.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Sep 7, 2012

Member

@DaSourcerer looks good to me too. Whats the main reason re-inventing the wheel and not using Zend_Http?

Member

cebe commented Sep 7, 2012

@DaSourcerer looks good to me too. Whats the main reason re-inventing the wheel and not using Zend_Http?

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Sep 7, 2012

Contributor

@samdark:

User agent should be changeable.

It will be. The idea is that you set it via CHttpClient.headers. I know, this isn't obvious and will need to be documented. However, I wanted to have as little "special purpose" headers as possible. They should all be treated equally.

Looks good to me except some thongs like "information purpose" params

Are you referring to CHttpClientRequest.fragment? That's mostly due to the behaviour of parse_url(). I think it's good to have anyway since we don't have a dedicated CUrl class ..

@cebe: Zend_Http is pretty much "one use only." I imagined a component that could also be used in batch jobs. Also: Zend_Http is a bit hard to integrate cleanly into another framework. It comes with dependencies on Zend's caching infrastructure etc. I thought I could do this better with a rewrite.

Contributor

DaSourcerer commented Sep 7, 2012

@samdark:

User agent should be changeable.

It will be. The idea is that you set it via CHttpClient.headers. I know, this isn't obvious and will need to be documented. However, I wanted to have as little "special purpose" headers as possible. They should all be treated equally.

Looks good to me except some thongs like "information purpose" params

Are you referring to CHttpClientRequest.fragment? That's mostly due to the behaviour of parse_url(). I think it's good to have anyway since we don't have a dedicated CUrl class ..

@cebe: Zend_Http is pretty much "one use only." I imagined a component that could also be used in batch jobs. Also: Zend_Http is a bit hard to integrate cleanly into another framework. It comes with dependencies on Zend's caching infrastructure etc. I thought I could do this better with a rewrite.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Sep 7, 2012

Member

It will be.

I was talking about default value. I'd like to set it once in config so it will be the same for all my requests.

Whats the main reason re-inventing the wheel and not using Zend_Http?

It actually makes sense for the reasons @DaSourcerer mentioned.

@DaSourcerer, have you checked ZF2 and SF2 implementations of the same component?

Member

samdark commented Sep 7, 2012

It will be.

I was talking about default value. I'd like to set it once in config so it will be the same for all my requests.

Whats the main reason re-inventing the wheel and not using Zend_Http?

It actually makes sense for the reasons @DaSourcerer mentioned.

@DaSourcerer, have you checked ZF2 and SF2 implementations of the same component?

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Sep 7, 2012

Contributor

I was talking about default value. I'd like to set it once in config so it will be the same for all my requests.

Me too :) That USER_AGENT_STRING constant will only come into play when no header has been set in the config.

have you checked ZF2 and SF2 implementations of the same component?

Well, I had a brief look at ZF2. I've been under the impression that it hasn't changed too much since ZF1. SF2 is a bit out of my focus, but I'll have a look. I got some inspiration from Habrai, though.

Contributor

DaSourcerer commented Sep 7, 2012

I was talking about default value. I'd like to set it once in config so it will be the same for all my requests.

Me too :) That USER_AGENT_STRING constant will only come into play when no header has been set in the config.

have you checked ZF2 and SF2 implementations of the same component?

Well, I had a brief look at ZF2. I've been under the impression that it hasn't changed too much since ZF1. SF2 is a bit out of my focus, but I'll have a look. I got some inspiration from Habrai, though.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Sep 7, 2012

Member

You meant Habari blogging software?

Member

samdark commented Sep 7, 2012

You meant Habari blogging software?

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Sep 17, 2012

Contributor

So, with test coverage on its way I'm getting close to actually open up a pull request this week. However, I'll need a method to parse in cookies. What are the chances of a static CHttpCookie::fromString() being accepted? Also: It looks like I'll need a CHttpUtils class for things like query string manipulation, http header sorting/weighting and URL parsing/building. Is any of this an issue?

Contributor

DaSourcerer commented Sep 17, 2012

So, with test coverage on its way I'm getting close to actually open up a pull request this week. However, I'll need a method to parse in cookies. What are the chances of a static CHttpCookie::fromString() being accepted? Also: It looks like I'll need a CHttpUtils class for things like query string manipulation, http header sorting/weighting and URL parsing/building. Is any of this an issue?

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Sep 17, 2012

Member

If it fits design it should not be an issue.

Member

samdark commented Sep 17, 2012

If it fits design it should not be an issue.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Nov 24, 2012

Member

@DaSourcerer any news on this one?

Member

samdark commented Nov 24, 2012

@DaSourcerer any news on this one?

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Nov 26, 2012

Contributor

@samdark: Sadly, it doesn't look too good. I'm still in hope of creating a PR in time for the RC. But it looks like this will only be possible by massively trimming the functionality. Especially cookie handling has prroven to be quite complex. I had hoped to (ab)use CFileCache for that, but it really looks like some kind of db-backed storage is needed. Likewiese, HTTP-caching will have to be implemented at a later point (meaning webapps will have to handle caching headers themselves for a while).

I still need to look at a CHeaderCollection class that'll be able to handle multiple headers of the same name.

I had the opportunity to look a bit through the implementations of ZF2 and Sf2: ZF2 is over-achieving things OOP-wise with headers; each header is parsed into a seperate object. I do not think this fits particularly well with Yii's focus on arrays. Sf2 seems to have implemented a complete browser in PHP. While that's certainly impressive, I don't think we will ever see for an implementation that is that much complete.

Contributor

DaSourcerer commented Nov 26, 2012

@samdark: Sadly, it doesn't look too good. I'm still in hope of creating a PR in time for the RC. But it looks like this will only be possible by massively trimming the functionality. Especially cookie handling has prroven to be quite complex. I had hoped to (ab)use CFileCache for that, but it really looks like some kind of db-backed storage is needed. Likewiese, HTTP-caching will have to be implemented at a later point (meaning webapps will have to handle caching headers themselves for a while).

I still need to look at a CHeaderCollection class that'll be able to handle multiple headers of the same name.

I had the opportunity to look a bit through the implementations of ZF2 and Sf2: ZF2 is over-achieving things OOP-wise with headers; each header is parsed into a seperate object. I do not think this fits particularly well with Yii's focus on arrays. Sf2 seems to have implemented a complete browser in PHP. While that's certainly impressive, I don't think we will ever see for an implementation that is that much complete.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Nov 26, 2012

Member

Moved to 1.1.14. @DaSourcerer I don't think massive trim of functionality and ideas is a good choice.

Member

samdark commented Nov 26, 2012

Moved to 1.1.14. @DaSourcerer I don't think massive trim of functionality and ideas is a good choice.

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Nov 26, 2012

Contributor

Okay ... Would it be fine if I'd opened a pull request as a preview? Once I'm finished, the final PR will be quite sizable, so I'd like to get some more feedback before I start to develop into the wrong direction.

Contributor

DaSourcerer commented Nov 26, 2012

Okay ... Would it be fine if I'd opened a pull request as a preview? Once I'm finished, the final PR will be quite sizable, so I'd like to get some more feedback before I start to develop into the wrong direction.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Nov 26, 2012

Member

Sure.

Member

samdark commented Nov 26, 2012

Sure.

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Dec 20, 2012

Contributor

My further research has led me to Guzzle which is looking like it would integrate much more nicely into Yii than any other lib so far.

Anyway, I'm still working on this. Since v1.1.14 is now the new goal, I'd like to invest some time into the CHttpClient interface and the backing infrastructure. I'll keep you updated.

Contributor

DaSourcerer commented Dec 20, 2012

My further research has led me to Guzzle which is looking like it would integrate much more nicely into Yii than any other lib so far.

Anyway, I'm still working on this. Since v1.1.14 is now the new goal, I'd like to invest some time into the CHttpClient interface and the backing infrastructure. I'll keep you updated.

DaSourcerer added a commit to DaSourcerer/yii that referenced this issue Mar 7, 2013

@iodragon

This comment has been minimized.

Show comment
Hide comment
@iodragon

iodragon Apr 2, 2014

any update for this?

iodragon commented Apr 2, 2014

any update for this?

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Apr 2, 2014

Contributor

@iodragon: Were you asking me or is this a general question?

Contributor

DaSourcerer commented Apr 2, 2014

@iodragon: Were you asking me or is this a general question?

@iodragon

This comment has been minimized.

Show comment
Hide comment
@iodragon

iodragon commented Apr 2, 2014

@DaSourcerer maybe both

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Apr 22, 2014

Contributor

So, here's the state of things as requested by @iodragon.

As before, I'm massively lagging behind. I freely admit, this is in parts due to my own perfectionism. Though, a far larger cause for the delays has been a number of personal hardhsips. One of them being a rather unpleasent medical condition imparing my ability to focus and thus tending to force me ceding coding alltogether for weeks or even months at a time.

With said condition sufficiently under control and a great personal incentive to finish CHttpClient (@cebe may know what is meant by that), I recently picked up work again. Current state is as follows:

  • HTTP/0.9 is implemented completely
  • GETting resources in HTTP/1.0 and 1.1 is very stable
  • Resources can be fetched via SSL
  • Both, gzip and bzip2 (preferred over gzip by e.g. LighTTPd) response decompression are working
  • Conditional/cached requests are working out-of-the box. This is a bit basic, as caching durations and the Vary header aren't honored yet.
  • HTTP basic auth is working
  • Support for trailers and chunk extensions. Trailers are merged into headers, chunk extensions are being logged (given a sufficiently high log level) and then disregarded.
  • Folded headers are unfolded and parsed correctly
  • Redirects (if RFC-conforming) can be followed

So far, the client is showing splendid speed. A new URL component allows for some nice transformations. A simple crawler can be implemented like this:

$request=Yii::app()->http->get('https://example.com/?action=view');
for($t=1; $t<=1024; ++$t)
{
    $request->url->params['id']=$t;
    echo "$t\t";
    $response=$request->send();
    if($response->isSuccessful())
    {
        preg_match('/<title>(.+)<\/title>/im',$response->body,$matches);
        $title=trim(strip_tags($matches[1]));
        echo $title.PHP_EOL;
    }
    else
        echo ">> {$response->status} {$response->message}".PHP_EOL;
}

There is also some neat method chaining. This example would fetch a page and print it out:

echo Yii::app()->http->get('http://example.org')->  //prepare the request
    disableCaching()->                              //don't send caching http headers
    addHeader('DNT','1')->                      //send the do-not-track header along
    send()->                                        //send the request out
    body                                            //print out the response's body

I am currently rewriting the socket codes as the current method of fetching response bodies doesn't work too well with persistent connections. As a by-product, the client is going to support authentication through client-side certificates whcih is quite handy when it comes to machine authentication.

Up next is some work on header management. I previously stated that I wanted to work with arrays only for this. Try as I might, this is insufficient as I need to rely on proper header value parsing and management. Just to illustrate the dilemma, this request:

GET http://example.org/ HTTP/1.1
Host: example.org:80
Accept: application/xhtml+xml, text/html, */*;q=0.9
TE: chunked

is semantically identical to this:

GET / HTTP/1.1
Host: example.org
Accept: application/xhtml+xml
Accept: text/html
Accept: */*;q=0.9

Especially weighted values are a problem. This is more of a challenge then it seems at first glance, because when you read in RFC 2616, sec. 19.4.1

HTTP is not a MIME-compliant protocol

It actually means

There are no MIME-Version and Content-Transfer-Encoding headers in HTTP. Everything else out of RFC 2045 and its little-know extensions and unheard-of RFCs applies.

So, there's that. I might have to borrow some algorithms out of Python's email package which is known to understand header folding and value quoting pretty well. Amazingly, it seems to be easier to parse MIME headers than to generate them correctly. Oh well ...

On the pro side: Implementing header value parsing correctly and having distinct classes for each header should give major advantages when handling caching headers and cookies. This would possibly make supporting digest authentication a breeze, too.

The last big chunk of coding would be to create a class hierarchy for message bodies. This is especially helpfull for multipart bodies who are needed for any usefull resource manipulation via PUT, POST and possibly PATCH. I already wrote some separate code for this which I hope to eventually pass in here.

Cookie management is something that brings its own set of problems, so I'll implement this as the very last feature.

As far as Yii 2 is concerned, I plan to port this client to it after it has been used some time in 1.1. This is mostly in an effort to not let any architectural flaws carry over into 2.0. I previously thought I could let the HTTP stream wrapper handle a lot of the logic there. But I ended up doing so much on raw sockets that I am no longer sure about that.

All in all, this is going to be a client that is nearly feature-complete regarding HTTP/1.1. Pretty much the only features that are going to be missing are request pipelining (this would require an additional abstraction layer and really isn't worth the effort when compared to persistent connections IMHO) and support for the Cookie2 header (hardly ever used). Having said so, it is unlikely this client is ever going to speak HTTP/2.0 or SPDY, as the way the protocol works has changed a lot as far as I can see.

Contributor

DaSourcerer commented Apr 22, 2014

So, here's the state of things as requested by @iodragon.

As before, I'm massively lagging behind. I freely admit, this is in parts due to my own perfectionism. Though, a far larger cause for the delays has been a number of personal hardhsips. One of them being a rather unpleasent medical condition imparing my ability to focus and thus tending to force me ceding coding alltogether for weeks or even months at a time.

With said condition sufficiently under control and a great personal incentive to finish CHttpClient (@cebe may know what is meant by that), I recently picked up work again. Current state is as follows:

  • HTTP/0.9 is implemented completely
  • GETting resources in HTTP/1.0 and 1.1 is very stable
  • Resources can be fetched via SSL
  • Both, gzip and bzip2 (preferred over gzip by e.g. LighTTPd) response decompression are working
  • Conditional/cached requests are working out-of-the box. This is a bit basic, as caching durations and the Vary header aren't honored yet.
  • HTTP basic auth is working
  • Support for trailers and chunk extensions. Trailers are merged into headers, chunk extensions are being logged (given a sufficiently high log level) and then disregarded.
  • Folded headers are unfolded and parsed correctly
  • Redirects (if RFC-conforming) can be followed

So far, the client is showing splendid speed. A new URL component allows for some nice transformations. A simple crawler can be implemented like this:

$request=Yii::app()->http->get('https://example.com/?action=view');
for($t=1; $t<=1024; ++$t)
{
    $request->url->params['id']=$t;
    echo "$t\t";
    $response=$request->send();
    if($response->isSuccessful())
    {
        preg_match('/<title>(.+)<\/title>/im',$response->body,$matches);
        $title=trim(strip_tags($matches[1]));
        echo $title.PHP_EOL;
    }
    else
        echo ">> {$response->status} {$response->message}".PHP_EOL;
}

There is also some neat method chaining. This example would fetch a page and print it out:

echo Yii::app()->http->get('http://example.org')->  //prepare the request
    disableCaching()->                              //don't send caching http headers
    addHeader('DNT','1')->                      //send the do-not-track header along
    send()->                                        //send the request out
    body                                            //print out the response's body

I am currently rewriting the socket codes as the current method of fetching response bodies doesn't work too well with persistent connections. As a by-product, the client is going to support authentication through client-side certificates whcih is quite handy when it comes to machine authentication.

Up next is some work on header management. I previously stated that I wanted to work with arrays only for this. Try as I might, this is insufficient as I need to rely on proper header value parsing and management. Just to illustrate the dilemma, this request:

GET http://example.org/ HTTP/1.1
Host: example.org:80
Accept: application/xhtml+xml, text/html, */*;q=0.9
TE: chunked

is semantically identical to this:

GET / HTTP/1.1
Host: example.org
Accept: application/xhtml+xml
Accept: text/html
Accept: */*;q=0.9

Especially weighted values are a problem. This is more of a challenge then it seems at first glance, because when you read in RFC 2616, sec. 19.4.1

HTTP is not a MIME-compliant protocol

It actually means

There are no MIME-Version and Content-Transfer-Encoding headers in HTTP. Everything else out of RFC 2045 and its little-know extensions and unheard-of RFCs applies.

So, there's that. I might have to borrow some algorithms out of Python's email package which is known to understand header folding and value quoting pretty well. Amazingly, it seems to be easier to parse MIME headers than to generate them correctly. Oh well ...

On the pro side: Implementing header value parsing correctly and having distinct classes for each header should give major advantages when handling caching headers and cookies. This would possibly make supporting digest authentication a breeze, too.

The last big chunk of coding would be to create a class hierarchy for message bodies. This is especially helpfull for multipart bodies who are needed for any usefull resource manipulation via PUT, POST and possibly PATCH. I already wrote some separate code for this which I hope to eventually pass in here.

Cookie management is something that brings its own set of problems, so I'll implement this as the very last feature.

As far as Yii 2 is concerned, I plan to port this client to it after it has been used some time in 1.1. This is mostly in an effort to not let any architectural flaws carry over into 2.0. I previously thought I could let the HTTP stream wrapper handle a lot of the logic there. But I ended up doing so much on raw sockets that I am no longer sure about that.

All in all, this is going to be a client that is nearly feature-complete regarding HTTP/1.1. Pretty much the only features that are going to be missing are request pipelining (this would require an additional abstraction layer and really isn't worth the effort when compared to persistent connections IMHO) and support for the Cookie2 header (hardly ever used). Having said so, it is unlikely this client is ever going to speak HTTP/2.0 or SPDY, as the way the protocol works has changed a lot as far as I can see.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 22, 2014

Member

Wow, thanks for the detailed information and great to see you back! :) Let me know if you need help with anything regarding this.

Member

cebe commented Apr 22, 2014

Wow, thanks for the detailed information and great to see you back! :) Let me know if you need help with anything regarding this.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 22, 2014

Member

A general question: is this really something that should be tightly coupled to yii or would it maybe be better to make it a library of its own which is then easily integrated into the framework (both 1.1 and 2.0)?

Member

cebe commented Apr 22, 2014

A general question: is this really something that should be tightly coupled to yii or would it maybe be better to make it a library of its own which is then easily integrated into the framework (both 1.1 and 2.0)?

@acorncom

This comment has been minimized.

Show comment
Hide comment
@acorncom

acorncom Apr 22, 2014

Contributor

If it isn't tightly coupled with Yii, the library might be more widely used by the PHP community (with increased activity, pull requests, etc). Maybe we could see about getting it listed here? http://thephpleague.com

But @DaSourcerer, what are your thoughts?

Contributor

acorncom commented Apr 22, 2014

If it isn't tightly coupled with Yii, the library might be more widely used by the PHP community (with increased activity, pull requests, etc). Maybe we could see about getting it listed here? http://thephpleague.com

But @DaSourcerer, what are your thoughts?

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer Apr 23, 2014

Contributor

Skimming through the code, I see dependencies on the following core classes:

  • CApplicationComponent
  • CComponent
  • CMap

Plus some calls to Yii::app() and Yii::createComponent(). That's not too bad yet. But I plan to take advantage of the event system in the near future in order to keep some headers in a request synchronized to certain changes in the request's URL component. That is a much more elegant and saner approach than what the code currently does: Setting those headers right before they are being sent out over the socket.

I would pretty much consider this to be a point of no return, as replicating some of the behaviours of CComponent and CMap is relatively hassle-free while duplicating the event system ... not so much.

Also consider that I layed everything out in a way that would integrate nicely into the Yii ecosystem. I clearly see @acorncom's point, but turning this into a library separated from Yii would force me to change a lot of the design. TBH, I'm not too fond of this.

Contributor

DaSourcerer commented Apr 23, 2014

Skimming through the code, I see dependencies on the following core classes:

  • CApplicationComponent
  • CComponent
  • CMap

Plus some calls to Yii::app() and Yii::createComponent(). That's not too bad yet. But I plan to take advantage of the event system in the near future in order to keep some headers in a request synchronized to certain changes in the request's URL component. That is a much more elegant and saner approach than what the code currently does: Setting those headers right before they are being sent out over the socket.

I would pretty much consider this to be a point of no return, as replicating some of the behaviours of CComponent and CMap is relatively hassle-free while duplicating the event system ... not so much.

Also consider that I layed everything out in a way that would integrate nicely into the Yii ecosystem. I clearly see @acorncom's point, but turning this into a library separated from Yii would force me to change a lot of the design. TBH, I'm not too fond of this.

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer May 2, 2014

Contributor

Short update: I'm close to having the new socket code finished and preparing MIME header handling. @cebe, @samdark: What are the chances of something involving state machines being pulled? Some folding rules in MIME are obscenely complex and using RegEx would very likely result into unmaintainably messy expressions ...

Contributor

DaSourcerer commented May 2, 2014

Short update: I'm close to having the new socket code finished and preparing MIME header handling. @cebe, @samdark: What are the chances of something involving state machines being pulled? Some folding rules in MIME are obscenely complex and using RegEx would very likely result into unmaintainably messy expressions ...

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark May 2, 2014

Member

Pretty high chances.

Member

samdark commented May 2, 2014

Pretty high chances.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe May 3, 2014

Member

can you show what kind of string you need to parse? If it is not a regular language it is fine not to use regex but I'd like to check that first.

Member

cebe commented May 3, 2014

can you show what kind of string you need to parse? If it is not a regular language it is fine not to use regex but I'd like to check that first.

@DaSourcerer

This comment has been minimized.

Show comment
Hide comment
@DaSourcerer

DaSourcerer May 5, 2014

Contributor

@cebe: I'd like to parse HTTP and MIME headers. That can be done with regular expressions since virtually every definition of those header fields relies on some flavour of the Backus-Naur Form. However, to properly match these, pretty much every feature PCRE has to offer would have to be used.

In contrast, all better libraries and toolkits (such as MimeKit) are using state machines for header separation and parsing. The author of MimeKit wrote an interesting rant on regex-based solutions.

Contributor

DaSourcerer commented May 5, 2014

@cebe: I'd like to parse HTTP and MIME headers. That can be done with regular expressions since virtually every definition of those header fields relies on some flavour of the Backus-Naur Form. However, to properly match these, pretty much every feature PCRE has to offer would have to be used.

In contrast, all better libraries and toolkits (such as MimeKit) are using state machines for header separation and parsing. The author of MimeKit wrote an interesting rant on regex-based solutions.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe May 5, 2014

Member

okay, got it. go ahead with the state machine ;)

Member

cebe commented May 5, 2014

okay, got it. go ahead with the state machine ;)

@samdark samdark closed this Oct 5, 2015

@cebe cebe removed this from the 1.1.17 milestone Oct 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment