Re: Re: Request for vote: HTTP_Status
| From: | Marshall Roch | Date: | Sat, 30 Aug 2003 08:42:09 +0000 |
| Subject: | Re: Re: Request for vote: HTTP_Status | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-20856@lists.php.net to get a copy of this message | ||
Stefan Neufeind wrote:
Comment to my vote you counted and to the "separate package" discussion: As already mentioned I like to have such an addition. But it would be nice if it could be integrated e.g. with HTTP_Header or something into 1 (!) package.[snip]
Ok, I don't disagree with you, but I don't see any one package that it fits well in. I'd say HTTP_Header because of the name, but that package is currently designed to "set/modify HTTP-Headers." If we expand it to process headers as well, then it might be a good solution. Merging them the way it stands now would mean including all of HTTP_Header without gaining any benefit from it. HTTP, perhaps, but that's also missing almost all response header processing. If we're going to put it in this package, we should also consider merging HTTP_Header and adding response header processing (like making a timestamp out of the Date header). HTTP_Request has a HTTP_Response class. This class takes a socket as input and breaks it apart into all of the different pieces (headers, body, etc). If this was its own class, it seems like the most logical place for header processing (and identifying response codes). Of course, that would be two classes in one night that I want to split up... -- Marshall Roch-1 for HTTP_Status as separate package.Yes, same for me - as already said before. :-)