Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
base system
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
22 Nov 2008 at 16:33 UTC
Updated:
10 Jan 2009 at 20:30 UTC
Jump to comment: Most recent file
Comments
Comment #1
dave reidInitial patch. I ran the tests that could be affected by the changes: aggregator, xml-rpc, and drupal_http_request tests (there are no openid tests) and I had 100% pass.
Edit: removed patch.
Comment #2
dave reidArg...wasn't the latest patch. This one is good.
Comment #3
c960657 commented+ * (optional) An array which can have any or all of the following keys:Isn't "one or more" instead of "any or all" better?
I know that you are just reformatting the existing Doxygen comment, but I suggest updating the description to be more in line with the terminology used in RFC 2616 now that you are touching the lines. I suggest something like this:
The rationale behind "header"/"value" vs. "name"/value is described in #327269: drupal_page_cache_header() should compare timestamp. The notation
name/valuerather thanname => valueappears to be a bit more widespread in core (though I personally prefer the name => value convention)."data" is renamed to "body".
"retry" is renamed to "max_redirects" - following a redirect can hardly be described as a retry.
The @return description would be more readable if it was formatted with bullets like the $options array and with mention of the actual property names.
Aren't global declarations usually put at the first line of the method?
+ foreach ($options['headers'] as $header => $value) {I suggest renaming $header to $name.
I hope you don't feel I am derailing the issue. I just got the impression that you were trying to do some general clean-up while array-itizing the function. :-)
Comment #4
dave reidThose are some great suggestions c960657 and I'll work on improving the documentation. I always hated the $retry parameter and how it did not match it's purpose.
Comment #5
dave reidRevised patch for peer review. I still need to finish the descriptions for the @return doc, so I'm still leaving this as code needs work.
Comment #6
dave reidRevised patch. I'm not comfortable renaming 'data' to 'body' since we already use $response->data in the return value. Renaming that object parameter is going to cause a lot of backwards compatibility headaches for contrib, so I'd like to get webchick or Dries's opinion on renaming 'data' to 'body'. As of this patch, this is now the current documentation for drupal_http_request:
Comment #7
dave reidMarked #64866: Pluggable architecture for drupal_http_request() postponed until this issue lands in HEAD. It will make that issue so, so much easier and nicer.
Comment #8
c960657 commentedTypo (containting).
Apart from that it looks good :-)
Comment #9
dave reidHah! I guess that's a combination of containing and tainting. Also found a spelling error on "messsage." Revised and spelling-error free.
Comment #11
dave reidRerolled for HEAD.
Comment #13
drewish commentedre-rolling around the aggregator module changes.
Comment #14
dries commentedCommitted to CVS HEAD. Thanks! :)
Comment #15
dries commentedActually, marking this 'code needs work' until the upgrade documentation has been updated.
Comment #16
dave reidDocumentation has been updated. See http://drupal.org/node/224333#drupal_http_request_parameters