Wow you've been busy! =)

I took this down a few weeks ago but only got around to checking it out now. Read through Response class and saw body, raw_body, headers and alarms went off NOOOO where's raw_header??? ...and then I saw $this->raw_headers were being populated in the constructor and it was only the property reference that was missing.

I quickly scanned my source and saw ahhh I can help with composer package etc, sure there are things I can do but when I came back to fork I realized that I was going to have to look deeper if I wanted to help. It was not easy but I think I found a few items that will be useful.

The commit messages will have additional comments but these should be among them.

• Added the raw_headers property reference to response
• Compose request header and added raw_header to Request object.
• Fixed response has errors and added more comments for clarity.
• Fixed header parsing to allow the minimum (status line only) and also cater for the actual CRLF ended headers as per RFC2616.
• Added the perfect test Accept: header for all Acceptable scenarios see @b78e9e82cd9614fbe137c01bde9439c4e16ca323 for details.
• Added default User-Agent header.
  • User-Agent: HttpFul/1.0 you might want to tweak the name and version number.
  • `(cURL/?.?.? (host) if all else fails but it should be able to find the curl version from uhm curl_version() I guess.
  • Then we get PHP/5.3.8 for example which should get populated from the core provided PHP_VERSION constant.
  • Then we check if we have $_SERVER['SERVER_SOFTWARE'] and remove PHP from there should it exist.
  • If SERVER_SOFTWARE is unavailable we are more than likely using CLI so check for TERM_PROGRAM and TERM_PROGRAM_VERSION from $_SERVER.
  • Finally add the HTTP_USER_AGENT string if it exists and close the support software section with ')' to wrap this up as the perfect User-Agent string to verify any issues we might have.
• To bypass this "default" operation simply add a User-Agent to the request headers even a blank User-Agent is sufficient and more than simple enough to produce me thinks.
• Completed test units for all the additions and a few extra ones see @a23e8c301dbe501ccb934c0ff7e690a334bd81b4 and @1741fd8427f8015c391023fcca844fa0641cc6b7 for details.
• Added phpunit coverage reporting and helped phpunit auto locate the tests a bit easier.

I like what you've done to this implementation but maybe a tad too user friendly for my liking, is there such a thing as too user friendly?.. not that this should demotivate you there definitely is a place for this. I might steel a few concepts if you don't mind =)

The huge focus on the request headers was different and it works quite intuitively but I don't see how this is an improvement on say:

<?php $request->header['X-My-Awesome-Header'] = 'this works fine';

Maybe this is where my gripe with the user friendliness comes in, I want to know that's my header and I want to set it as I expect it without the camelCasing and "with" parsing and all the other bells getting in the way. Maybe if I sleep over it I will see things differently... we'll see.

Keep up the good work!

Implemented basic feature to upload files.

Use:

\Httpful\Request::post($this->url) ->body(array()) ->attach(array('indexToPost' => '/path/to/file')) ->send()

The content type should be multipart/form-data Method should be POST Data should be array

I am using the latest version(httpful-0.2.0.phar) of HTTPFul phar. On the hosted setup I get following problem: I have included phar as include "./httpful.phar"; .......................... PHP Warning: include(): Failed opening 'phar://httpful.phar/Httpful/Bootstrap.php' for inclusion (include_path='.:') in /var/www/tut/soapsync/httpful.phar on line 4 PHP Fatal error: Class 'Httpful\Bootstrap' not found in /var/www/tut/soapsync/httpful.phar on line 5

while on my local(dev) setup it works fine.

httpful don't seem to handle "100 continue" reply's

I have added a new header to line 734 in Response.php :

    $headers[] = $accept;
+  $headers[] = 'Expect:'; 

There's a lot of talk about this issue on the net, see eg.

http://www.infernodevelopment.com/expect-100-continue-header-twitter-api-error-using-php-curl http://www.iandennismiller.com/blog/2009/09/curl-http1-1-100-continue-and-multipartform-data-post/

Hello

Maybe I'm just new at this but I get this error no matter if I use the .phar or install using Composer (successfully). Monolog works so I don't think it's a problem with Composer. I've tried downgrading but to no avail, still the same error:

Fatal error: Class 'Request' not found in

I've tried both the Twitter and Google samples but it seems to be some kind of include problem?

Update src/Httpful/Response/Headers.php If a header appears more than once, it must also be able to  be represented as a single header with a comma-separated list of values.  We transform accordingly.

Well, the cookies have commas on them on the date field so i'm using a double pipe for delimiter.

Set-Cookie: cookie_1=42de533-b4d2-4f28-8982-ccda555061a8; Domain=www.mydomain.com; Expires=Tue, 12-Feb-13 17:10:28 GMT; Path=/; HttpOnly  Set-Cookie: cookie_2=somevalue; Domain=www.mydomain.com; Expires=Tue, 12-Feb-13 15:10:28 GMT; Path=/; HttpOnly

Instead of specifying all of the query string parameters directly in the URL, you can now do

Request::get("http://api.flickr.com/services/rest/")
    ->param("api_key", $apiKey)
    ->param("format", "json")
    ->param("nojsoncallback", 1);
    ->param("photo_id", $photoId)
    ->param("method", "flickr.photos.getInfo")

which I would consider more elegant and concise than creating one, very long URL with all of the parameters embedded, and their values interpolated in the string.

Hi, The phar file is apparently not located at https://github.com/downloads/nategood/httpful/httpful.phar Could you please provide me the location of the same? Thanks

Hi!

I've noted this bug after commit https://github.com/nategood/httpful/commit/ef6a59c9b4c906687d47ce7dff93587674fcee53

If you set 'Content-Length' to 0 some webserver/library won't see the body...

I've reverted to previous commit and everything works fine.

I'm still learning GH's PullRequest feature, and the diff seems longer than I expected, but it should do the trick: XML serializing and parsing in Httpful.

I added logging support(with a user-specifiable logging function) and a test server to the HttpfulTests script.

Requires PHP 5.4 for the built in server. Might be advisable to do PHP version checking to make sure the tests still work on PHP < 5.4.

Hello devs!

I'm having difficulties finding how to achieve what I want using this library. Is there any known documentation for this library. Please help me finding it.

Thank You.

$response = \Httpful\Request::post($url)
->expectsJson()
->body(['abc'=>123], \Httpful\Mime::FORM)
->send();

results in incorrect response body parsing, for example: Array (size=1) '{"exampleResponseFromServer":"data processed successfully"}' => string '' (length=0) (the entire raw response body is put in an array key and the array value is empty string)

When ->expectsJson() is called after ->body() the response JSON is parsed correctly.

Hey there!

I belong to an open source security research community, and a member (@ay-kay) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

This PR is trying to fix the issue with a compressed response, in my case, it was "gzip" compression. For example, if we get "Content-Encoding: gzip" from the server side we will get the exception with the message "Unable to parse the response as JSON: Control character error, possibly incorrectly encoded"

The point is to allow curl to decode the response automatically if it is compressed and then later every parser can continue to do their jobs without any issue.

Please let me know what do you think.

Thanks!

Can you add return types for PHP 8.1 to remove warnings?

In that line https://github.com/nategood/httpful/blob/master/src/Httpful/Response/Headers.php#L47 return type bool should be added to do that.

Now it ends up with:

Method "ArrayAccess::offsetUnset()" might add "void" as a native return type declaration in the future. Do the same in implementation "Httpful\Response\Headers" now to avoid errors or add an explicit @return annotation to suppress this message.

Return type of Httpful\Response\Headers::offsetGet($offset) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice

Return type of Httpful\Response\Headers::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice

• Other methods defined in \ArrayAccess and \Countablealso should be fixed.