Handling in HttpTransport when the requested uri does not exist #1431
Conversation
|
These came up when testing bad urls. The challenge was that fsockopen() sends a warning when the uri is not there ... the sending of the warning was making it very difficult to handle problem so this was the solution I finally came to after going around in circles for a while. |
|
Well .. I agree consistent is good and as you see I also came to the conclusion that silencing was the only option for fsocketopen(). The no conent condition is different than the bad url condition. I also think it's worth considering that there may only be headers and no body (or body and no headers) to cover all scenarios. |
|
There was a reason for doing it twice but I can't remember what it was (although I will test again with your version and see if it copes with all of my cases). I guess that it really doesn't matter that there are two different exceptions happening, one where the host is not foundand the other where it can't be opened for another reason. |
|
@elinw Besides in my opinion in your previous code both assertions for Thanks for taking time at it. |
|
Yes I was trying to remember why I did that and I think I just was avoiding touching the existing code for no good reason and really more focused on the empty $content problem. |
|
Wow that was a not easy exercise in rebasing |
| // Split the response into headers and body. | ||
| $response = explode("\r\n\r\n", $content, 2); | ||
|
|
||
| // Get the response headers as an array. | ||
| $headers = explode("\r\n", $response[0]); | ||
|
|
||
| if (empty($response[1])) | ||
| { | ||
| throw new UnexpectedValueException('No [1] offset in response.'); |
There was a problem hiding this comment.
If we got headers and an empty body, I'm not sure this is necessarily an exception.
There was a problem hiding this comment.
Went and looked at the spec, a HEAD request by definition won't return a body:
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.
So we really shouldn't return an exception here.
Handling in HttpTransport when the requested uri does not exist
The transports are currently not handling it well when the domain for a requested uri completely does not exist. At this point they are somewhat inconsistent in what they do (e.g. stream silences the message and then throws an exception similarly to what I propose here for socket). Rather than use a generic exception message this uses php and curl errors to give more detailed information about what went wrong.