| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Use a tempfile instead of a StringIO object
|
| | |
| |
| |
| |
| |
| | |
This provides a socket.fileno(), so
libraries that call select.poll() work properly.
Also supports mocking huge responses larger than memory, if needed.
|
| |/
|
|
|
|
|
| |
The bytes() constructor, when given an integer, creates a
bytes object of that length, instead of casting the number to a
string representation. This change uses str() to cast the integer,
and then relies on the later utf8() call to convert it to bytes.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reopens https://github.com/gabrielfalcao/HTTPretty/pull/145. Reopened as a new PR because Travis didn't seem to be running the correct tests. Removed the irrelevant changes, such as PEP8 and the `self.truesock.settimeout(0)` change.
HTTPretty does not behave correctly when using regex matching, HTTPS and custom ports. When this scenario is triggered, a timeout/max retries exceeded error occurs.
To duplicate run:
```python
@httpretty.activate
def exceed_max_retries_with_custom_port_and_https():
HTTPretty.register_uri(
HTTPretty.GET,
re.compile('https://api.yipit.com:1234/v1/deal;brand=(?P<brand_name>\w+)'),
body='meow'
)
uri = 'https://api.yipit.com:1234/v1/deal;brand=gap?first_name=chuck&last_name=norris'
response = requests.get(uri)
return response.content
```
Cause
--
The combination of a regex URI, custom port, and HTTPS causes HTTPretty to get stuck at https://github.com/gabrielfalcao/HTTPretty/blob/2e814635fff916d3a8c246ca010245362266c89f/httpretty/core.py#L323 and eventually raise this error:
```
ConnectionError: HTTPSConnectionPool(host='api.yipit.com', port=1234): Max retries exceeded with url: /v1/deal;brand=gap?first_name=chuck&last_name=norris (Caused by <class 'socket.error'>: [Errno 36] Operation now in progress).
```
This error happens because URI schema's are reconstructed incorrectly during the URI matching.
This should fail (http != https), but it does not!
```python
@httpretty.activate
def broken_reconstruction_of_uri_schema():
uri = 'api.yipit.com:1234/v1/deal'
HTTPretty.register_uri(HTTPretty.GET,
'https://' + uri,
body=lambda method, uri, headers: [200, headers, uri]
)
response = requests.get(uri)
expect(response.text).to.equal('http://' + uri) # incorrect!
```
Solution
--
To correct the internal confusion between HTTP and HTTPS ports, we need to separate the two in our DEFAULT/POTENTIAL PORTS lists. When URIMatcher encounters a non-regex URI it uses URIInfo.from_uri to add
the URIs port to the known ports. This behavior is now added for regex URIs.
We now use the DEFAULT_PORTS lists in HTTPretty.reset() to reset the POTENTIAL_PORTS lists. Also, to avoid using the global keyword, we do an in-place reset with intersection_update.
Added the following tests:
- test_httpretty_should_work_with_non_standard_ports
- test_httpretty_reset_by_switching_protocols_for_same_port
- test_httpretty_should_allow_registering_regexes_with_port_and_give_a_proper_match_to_the_callback
|
| |\
| |
| | |
Adding parsed_body parameter to simplify checks
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
parsed_body attempts to parse the post body if it matches a compatible content type
* content is returned unaltered if it's not a compatible type
* content parses json if content-type type is application/json
* content parse querystring params if content-type is application/x-www-form-urlencoded
* if the value cannot be parsed for any reason, it is unaltered
|
| |\ \
| | |
| | | |
Don't duplicate http ports number
|
| | |/
| |
| |
| |
| | |
Use a set instead of a list to store ports in the POTENTIAL_HTTP_PORTS.
Restore it to its initial value every tests that modify it.
|
| |/ |
|
| | |
|
| |
|
|
|
| |
Functional test change the content of POTENTIAL_HTTP_PORTS
but don't reset it. Ignore those changes.
|
| |
|
|
|
|
|
|
|
|
|
| |
when HTTPretty.enable(), we should contine to do DNS query,
like it's done in the
test_httpretty_should_not_raise_on_socket_send_when_uri_not_registered
test.
The test test_httpretty_should_raise_on_socket_send_when_uri_registered
is written to check that the RuntimeError is still raised when
the port is used for http traffic.
|
| | |
|
| |\
| |
| | |
Remove 2.x style unicode literals
|
| | | |
|
| | | |
|
| |/
|
|
|
|
| |
HTTPretty calculates Content-Length as the length of the body in characters,
when `body` is `unicode` of multibyte character set.
But it should be the length of the body in bytes.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
socket implementation, some raise exceptions that we don't care about in this instance. This could be fixed with mocking
|
| |
|
|
| |
to the underlying socket
|
| |
|
|
| |
the underlying socket
|
| |
|
|
| |
to the underlying socket
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
