The current implementation only returns the status message if there is an error and never returns the protocol.

I'm suggesting that we return this info because some times you may want to feed the original response from the server into another program or proxy it on. My philosophy on this is that the client should interpret the data for the implementer but not hide any of it. Ideally, I think this structure is best represented in a class wherein the user could always access the properties like the raw request, but barring that, this serves my purpose and perhaps others as well.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pwolanin’s picture

Version: 6.x-dev » 7.x-dev
pwolanin’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch failed testing.

pwolanin’s picture

Status: Needs work » Needs review
FileSize
643 bytes
mr.baileys’s picture

Status: Needs review » Needs work
Issue tags: +Quick fix, +Needs documentation

I think this is a nice improvement. Some comments/questions after reviewing this patch:

  1. The doxygen comment preceding drupal_http_request should also be changed as part of this patch (since return values are added/altered)
  2. Having the status message in both $result->error and $result->status_message (in case of an error) seems a bit confusing to me. What about making $result->error a boolean, and adjusting documentation to point people towards $result->code and $result->status_message for error information?
  3. While we're at it, wouldn't it make sense to rename $result->code to $result->status_code so we've got $result->status_code and $result->status_message?

I realize #2 and #3 might have a big impact on (read: break) a lot of code, but it does seem more self-explanatory to me, so I'm interested to hear what others think about this... Setting back to CNW for #1. Tagged "Needs documentation" to make sure the api docs are adjusted after this change...

pwolanin’s picture

The goal was a simple (back-portable to D6) fix - so let's start with just the original change plus doxygen.

pwolanin’s picture

Also, the error may get set with a message before it even attempts a request, so there may be no status message.

pwolanin’s picture

Status: Needs work » Needs review
FileSize
1.79 KB
JacobSingh’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me

Dries’s picture

Status: Reviewed & tested by the community » Needs work

This looks good to me to, but can we write a quick test for this please? Thanks!

pwolanin’s picture

I probably could, but really? This is trivial functionality.

JacobSingh’s picture

I don't see any test worth writing here because the code cannot be excersized cleanly.

For this function to be testable, the library would need to be written in an OO format, or at least broken down into half a dozen functions.

-J

JacobSingh’s picture

Status: Needs work » Reviewed & tested by the community
Dave Reid’s picture

Status: Reviewed & tested by the community » Needs work

The function already has a few tests already written (modules/simpletest/tests/common.test). A test for this feature would be easy:

  $request = drupal_http_request(url('pagedoesnotexist', array('absolute' => TRUE)));
  $this->assertEqual($request->protocol, 'HTTP/1.0');
  $this->assertEqual($request->code, '404');
  $this->assertEqual($request->status_message, 'Not Found');

Four lines. :)

JacobSingh’s picture

Sure, I suppose we can add those lines, but what I meant was that this function cannot have a unit test. It can have a system test (which I suppose it has), but a unit test by purist definition should never talk to a database or talk across a network. It should simply exercise the conditionals and code flow. For instance, if network access was disabled in the php testbed this was run on, it would fail with an exception, but it would not be caught, and it would not test that the function can interpret response codes are parse them (which is what this bit of code is doing).

If you introduce a network environment (actually making an HTTP request), then you are not testing just that unit but a larger system which is expected to respond (or not respond) to that request. I'm not suggesting we build a huge test harness (although using an OO HTTP request library would be a lot easier to do this with), but IMHO, I don't think this test adds a ton of value to the implementation.

http://www.artima.com/weblogs/viewpost.jsp?thread=126923 is a nice writeup on unit tests and separation of interface from implementation.

-J

pwolanin’s picture

Status: Needs work » Needs review
FileSize
2.88 KB

ok, added tests based on the suggestion.

Absent the patch to common.inc, this one set of tests gives: 20 passes, 2 fails, and 2 exceptions

+ patch: 22 passes, 0 fails, and 0 exceptions

Dries’s picture

Status: Needs review » Fixed

Thanks for the extra test -- those are good enough for now. Committed to CVS HEAD.

pwolanin’s picture

Version: 7.x-dev » 6.x-dev
Status: Fixed » Patch (to be ported)

I think we should back-port to 6.x, since we're just adding extra information, not changing anything already being used.

c960657’s picture

Status: Patch (to be ported) » Needs review
FileSize
1.63 KB

+ $this->assertEqual($result->protocol, 'HTTP/1.0', t('Result protocol is set as HTTP/1.0'));
This tests fails on my box (Debian Etch with PHP 5.2.0 and Apache 2.2.3) with PHP running as Apache module as well as CGI.

The web server responds in HTTP/1.1 even if the request made by drupal_http_request() is HTTP/1.0. $_SERVER[SERVER_PROTOCOL] is HTTP/1.0 as expected, but the server responds with HTTP/1.1 404 Not found even if header('HTTP/1.0 404 Not found') is called from PHP.

This is due to a bug in PHP that was fixed in PHP 5.2.1. I suggest we just skip the test for PHP 5.2.0.

c960657’s picture

Version: 6.x-dev » 7.x-dev
mcrittenden’s picture

Nice catch c960657. Your fix looks good to me although I can't test with PHP 5.2.0.

JacobSingh’s picture

heh, hence my point that this is not a unit test.

;)

Dries’s picture

How about we just remove that one line from the tests -- or we comment it out for the time being. Adding a PHP version check feels like one step too far.

pwolanin’s picture

How about this - we can just check if something is returned for the protocol, rather than looking for any specific version.

Dries’s picture

Status: Needs review » Fixed

Committed to CVS HEAD.

pwolanin’s picture

Version: 7.x-dev » 6.x-dev
Status: Fixed » Patch (to be ported)
sun’s picture

Version: 6.x-dev » 7.x-dev
Status: Patch (to be ported) » Needs work
  *       An integer containing the response status code, or the error code if
  *       an error occurred.
+ *   - protocol
+ *      The response protocol (e.g. HTTP/1.1 or HTTP/1.0).
+ *   - status_message
+ *      The status message from the response, if a response was received.
  *   - redirect_code
  *       If redirected, an integer containing the initial response status code.

Wrong indentation.

pwolanin’s picture

Status: Needs work » Needs review
FileSize
906 bytes
mr.baileys’s picture

Status: Needs review » Reviewed & tested by the community

This is ready to be commited...

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed. Thanks!

webchick’s picture

Version: 7.x-dev » 6.x-dev
Status: Fixed » Patch (to be ported)
Issue tags: -Needs documentation

Also, looks like documentation needs have been addressed.

Restoring previous status.

Dries’s picture

Version: 6.x-dev » 7.x-dev
Status: Patch (to be ported) » Fixed
Issue tags: +Needs documentation

Committed. Thanks.

pwolanin’s picture

Version: 7.x-dev » 6.x-dev
Status: Fixed » Patch (to be ported)

ok, now for 6.x

c960657’s picture

Status: Patch (to be ported) » Needs review
FileSize
2.66 KB

Backport. Not sure whether this qualifies for inclusion in D6.

pwolanin’s picture

Since we are adding information (not removing or changing any currently returned) it seems like a reasonable backport to me.

pwolanin’s picture

patch didn't apply for me - just the doxygen part. Here's a re-roll.

sun’s picture

Issue tags: -Needs documentation

.

pwolanin’s picture

this is pretty trivial - ready to commit?

c960657’s picture

Status: Needs review » Reviewed & tested by the community
Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Looks good, committed.

Status: Fixed » Closed (fixed)
Issue tags: -Quick fix

Automatically closed -- issue fixed for 2 weeks with no activity.