Permalink
Browse files

default values

  • Loading branch information...
jrivero committed Mar 4, 2011
1 parent 7965e91 commit 293d5f32331c3ba2b2117bf4d96c0f79717be2e8
Showing with 17 additions and 7 deletions.
  1. +17 −7 lib/curl_response.php
View
@@ -48,15 +48,25 @@ function __construct($response) {
# Extract the version and status from the first header
$version_and_status = array_shift($headers);
- preg_match('#HTTP/(\d\.\d)\s(\d\d\d)\s(.*)#', $version_and_status, $matches);
- $this->headers['Http-Version'] = $matches[1];
- $this->headers['Status-Code'] = $matches[2];
- $this->headers['Status'] = $matches[2].' '.$matches[3];
+ if (preg_match('#HTTP/(\d\.\d)\s(\d\d\d)\s(.*)#', $version_and_status, $matches)) {
+ $this->headers['Http-Version'] = $matches[1];
+ $this->headers['Status-Code'] = $matches[2];
+ $this->headers['Status'] = $matches[2].' '.$matches[3];
+ } else {
+ $this->headers['Http-Version'] = null;
+ $this->headers['Status'] = null;
+ $this->headers['Status-Code'] = null;
+ }
+ # Set default
+ $this->headers['Content-Type'] = null;
+ $this->headers['Content-Length'] = 0;
+
# Convert headers into an associative array
foreach ($headers as $header) {
- preg_match('#(.*?)\:\s(.*)#', $header, $matches);
- $this->headers[$matches[1]] = $matches[2];
+ if (preg_match('#(.*?)\:\s(.*)#', $header, $matches)) {
+ $this->headers[$matches[1]] = $matches[2];
+ }
}
}
@@ -75,4 +85,4 @@ function __toString() {
return $this->body;
}
-}
+}

7 comments on commit 293d5f3

@nickl-

This comment has been minimized.

Show comment Hide comment
@nickl-

nickl- Jun 19, 2012

Chances are slim that you will receive a response without a status line as RFC2616 does not indicate that it is optional, like the headers. I guess it is safe to check that preg_match is true but we certainly don't have to verify that a status line has been sent or to check if a colon ":" exists in a header field, or am I mistaken?

If all you want to accomplish is to ensure that these properties are initialized then I would rather see it happen in the constructor or at property declaration. What do you think?

Chances are slim that you will receive a response without a status line as RFC2616 does not indicate that it is optional, like the headers. I guess it is safe to check that preg_match is true but we certainly don't have to verify that a status line has been sent or to check if a colon ":" exists in a header field, or am I mistaken?

If all you want to accomplish is to ensure that these properties are initialized then I would rather see it happen in the constructor or at property declaration. What do you think?

@nickl-

This comment has been minimized.

Show comment Hide comment
@nickl-

nickl- Jun 20, 2012

Lets see if we can't do something about this too.

Lets see if we can't do something about this too.

@jrivero

This comment has been minimized.

Show comment Hide comment
@jrivero

jrivero Jun 20, 2012

Owner

This code is little obsolete. It's true what you mention that it is difficult (should be impossible) not be a status in the header, but has it ever happened... Not sought to verify the existence of ":" what is intended is to get all headers knowing that this character always appears as a separator.

I have long planned rewrite following the ideas of Kenneth Reitz in Requests (http://kennethreitz.com/requests-python-http-module.html). I also liked the project httpful ;)

Owner

jrivero replied Jun 20, 2012

This code is little obsolete. It's true what you mention that it is difficult (should be impossible) not be a status in the header, but has it ever happened... Not sought to verify the existence of ":" what is intended is to get all headers knowing that this character always appears as a separator.

I have long planned rewrite following the ideas of Kenneth Reitz in Requests (http://kennethreitz.com/requests-python-http-module.html). I also liked the project httpful ;)

@nickl-

This comment has been minimized.

Show comment Hide comment
@nickl-

nickl- Jun 20, 2012

I did some work for httpful it's ok but I have some other ideas and this is where I am taking this project.

Still busy with some changes before I will push the new version and have everybody freak out.

This is where your contribution ended up:

<?php

  private   $reflect = null;

  protected $cookie_file = null,
            $follow_redirects = true,
            $validate_ssl = false,
            $request = null,
            $userpwd = false;

  public    $options = array(),
            $headers = array(
                  'Accept' => null,
                  'Accept-Charset' => null,
                  'Accept-Encoding' => null,
                  'Accept-Language' => null,
                  'Authorization' => null,
                  'Connection' => null,
                  'Cookie' => null,
                  'Expect' => null,
                  'From' => null,
                  'Host' => null,
                  'If-Match' => null,
                  'If-Modified-Since' => null,
                  'If-None-Match' => null,
                  'If-Range' => null,
                  'If-Unmodified-Since' => null,
                  'Max-Forwards' => null,
                  'Proxy-Authorization' => null,
                  'Range' => null,
                  'Referer' => null,
                  'TE' => null,
                  'User-Agent' => null,
            );

I did some work for httpful it's ok but I have some other ideas and this is where I am taking this project.

Still busy with some changes before I will push the new version and have everybody freak out.

This is where your contribution ended up:

<?php

  private   $reflect = null;

  protected $cookie_file = null,
            $follow_redirects = true,
            $validate_ssl = false,
            $request = null,
            $userpwd = false;

  public    $options = array(),
            $headers = array(
                  'Accept' => null,
                  'Accept-Charset' => null,
                  'Accept-Encoding' => null,
                  'Accept-Language' => null,
                  'Authorization' => null,
                  'Connection' => null,
                  'Cookie' => null,
                  'Expect' => null,
                  'From' => null,
                  'Host' => null,
                  'If-Match' => null,
                  'If-Modified-Since' => null,
                  'If-None-Match' => null,
                  'If-Range' => null,
                  'If-Unmodified-Since' => null,
                  'Max-Forwards' => null,
                  'Proxy-Authorization' => null,
                  'Range' => null,
                  'Referer' => null,
                  'TE' => null,
                  'User-Agent' => null,
            );
@jrivero

This comment has been minimized.

Show comment Hide comment
@jrivero

jrivero Jun 26, 2012

Owner

instead of putting such a definition of variable to null rather do a getter method to address this.

Have initial code of your idea?

Owner

jrivero replied Jun 26, 2012

instead of putting such a definition of variable to null rather do a getter method to address this.

Have initial code of your idea?

@jrivero

This comment has been minimized.

Show comment Hide comment
@jrivero

jrivero Jun 26, 2012

Owner

guzzle, you know? http://guzzlephp.org/

Owner

jrivero replied Jun 26, 2012

guzzle, you know? http://guzzlephp.org/

@nickl-

This comment has been minimized.

Show comment Hide comment
@nickl-

nickl- Jun 27, 2012

Yep have that here too also some interesting ideas there.

There is also PEAR2_HTTP_Request
Which caters for 5 different engines

  • PECL HTTP
  • cURL extension
  • HTTP PHP streams
  • PHP Sockets
  • Filesystem for mock internet

I am aiming at a complete cURL library to make understanding curl better instead of all those separate functions and try to harness all it's capabilities in an intuitive way. We would want to show the functionality and not hide it so I fear overloading the properties won't do the trick. I am currently considering creating a class for each header field and abstracting parents per grouped headers so they may describe themselves properly, not only te cURL but to us humans alike. This will facilitate a logical location for implementing the different requirements per the HTTP specifications. I already parsed rfc4229 , which lists all the HTTP headers currently registered with IANA, into a collection waiting for me to decide what to do with the 133 headers and this is for HTTP only.

This is an example of the information collected:

<?php

  'Transfer-Encoding' =>
  array (
    0 => 'Status: standard

   Author/change controller:
      IETF  (iesg@ietf.org)
      Internet Engineering Task Force

   Specification document(s):
      RFC2616 [11]',
    1 => 'standard',
    2 => 'RFC2616',
    3 => '11',
    4 => '[11]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   ',
  ),

cURL also has support for 23 protocols and these now have their own classes to have a logical point for them to implement their usage in a logical fashion. So what started as a rewrite and modernization of Shuber's curl has turned into a major research project but all things considered, after merging all the other branches and each person's little hack/patch for ssh and file upload etc, I think this is the best way to approach a cURL module instead of throwing everything together in a if this then that mess. Separating the implementations and grouping functionality where they relate will moke using, maintaining and improving the codebase much simpler in the long term.

What do you think?

Yep have that here too also some interesting ideas there.

There is also PEAR2_HTTP_Request
Which caters for 5 different engines

  • PECL HTTP
  • cURL extension
  • HTTP PHP streams
  • PHP Sockets
  • Filesystem for mock internet

I am aiming at a complete cURL library to make understanding curl better instead of all those separate functions and try to harness all it's capabilities in an intuitive way. We would want to show the functionality and not hide it so I fear overloading the properties won't do the trick. I am currently considering creating a class for each header field and abstracting parents per grouped headers so they may describe themselves properly, not only te cURL but to us humans alike. This will facilitate a logical location for implementing the different requirements per the HTTP specifications. I already parsed rfc4229 , which lists all the HTTP headers currently registered with IANA, into a collection waiting for me to decide what to do with the 133 headers and this is for HTTP only.

This is an example of the information collected:

<?php

  'Transfer-Encoding' =>
  array (
    0 => 'Status: standard

   Author/change controller:
      IETF  (iesg@ietf.org)
      Internet Engineering Task Force

   Specification document(s):
      RFC2616 [11]',
    1 => 'standard',
    2 => 'RFC2616',
    3 => '11',
    4 => '[11]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   ',
  ),

cURL also has support for 23 protocols and these now have their own classes to have a logical point for them to implement their usage in a logical fashion. So what started as a rewrite and modernization of Shuber's curl has turned into a major research project but all things considered, after merging all the other branches and each person's little hack/patch for ssh and file upload etc, I think this is the best way to approach a cURL module instead of throwing everything together in a if this then that mess. Separating the implementations and grouping functionality where they relate will moke using, maintaining and improving the codebase much simpler in the long term.

What do you think?

Please sign in to comment.