Repository navigation
Version 1.0, working notes. #1092
Description
Here are my current working notes on our remaining 1.0 items...
HTTPX 1.0
- Exception hierarchy. - See Exceptions - Documentation, Hierarchy & Naming. #949 (comment), Exception hierarchy #1095
- Drop chardet. - See Prefer defaulting to utf-8, rather than using chardet autodetect #1078 (comment)
- Optional HTTP/2 installs. - See Optional HTTP/2 httpcore#121
- Drop HSTS. - See Consider dropping HSTS preloading #1102
- Drop URLLib3Transport into external package.
- Context managed transports. - See Add support for streaming responses to
ASGITransport#998 (comment) tho I need to explain this one more thoroughly.
Minor:
- Drop
httpx.StatusCodesin favour ofhttpx.codes. See Single consistent name for status codes #1088 -
PoolLimits->Limits,pool_limits->limits. - Strict Timeout(...) defaults. Simplify keyword arguments. See httpx.Timeout must include a default #1085
- Review all methods/attributes on the models classes. Eg. See Consistent multidict methods #1089. Also
.call_nextmight need to be private..timermight need looking at. -
httpx.create_ssl_context(...)- See Standalonecreate_ssl_context()function? #983
Not strictly required, but worth looking at:
- Review
rfc3986vs.irlvs.urlcore. - See Can't handle URLs with @ character in userinfo section #328 (comment) - Mount API. - See Mount API #977. Not strictly required for 1.0, but we want to make sure we've handling managed transports properly, and not missing any low-level
httpcoreAPI required to support them. - Expose ContentStream API. Perhaps?
- Upgrade API. - See WebSockets support. #304 (comment)
- Server side requests and responses. - See Server-side requests/responses #1091
API Reference
Here's a high-level API reference...
Helper functions
request, stream, get, options, head, post, put, patch, delete
Clients
Client, AsyncClient
Models
Response, Request, URL, QueryParams, Headers, Cookies
Configuration
Limits, Proxy, Timeout
Authentication
Auth, BasicAuth, DigestAuth
Transports
ASGITransport, WSGITransport
Status Codes
codes
Exceptions
RequestErrorAll exceptions that can occur during a.request()TransportErrorThese all have counterparts inhttpcoreTimeoutExceptionConnectTimeoutReadTimeoutWriteTimeoutPoolTimeout
NetworkErrorConnectErrorReadErrorWriteErrorCloseError
ProxyErrorProtocolError
DecodingErrorContentDecodingErrorTextDecodingError
TooManyRedirectsRequestBodyUnavailableInvalidURL
HTTPStatusError- Occurs during.raise_for_statusNotRedirectResponse- Occurs if calling.next()without properly checking.is_redirect_responseCookieConflict- Can occur withresponse.cookies.get(...)StreamErrorStreamConsumed- Occurs if attempting to iterate over the stream twiceResponseNotRead- Occurs if accessing.contentwithout having.read()the streamRequestNotRead- Occurs if accessing.contentwithout having.read()the streamResponseClosed- Occurs if attempting to read the stream after response is already closed
Dependencies
Here's how our lovely & minimal core non-optional dependancies would look...
Depending on our assessment of #328 (comment)
httpcoreh11sniffio
rfc3986idna
certifi
Activity
[-]Version 1.0, revisited.[/-][+]Version 1.0, working notes.[/+]StephenBrown2 commentedon Jul 29, 2020
Gonna put in another request for built-in retries, though I understand if the answer is still "no" or "not for 1.0".
florimondmanca commentedon Jul 30, 2020
Went ahead and created #1102 to better track the "Drop HSTS" item - also updated the description here.
lovelydinosaur commentedon Jul 30, 2020
@StephenBrown2 Fair question yup, seems to me that it's absolutely a 1.1 item. It's a great feature that we should look at, but I don't think there's any pressing need for it to block a release marked as 1.0, with the API stability that implies.
lovelydinosaur commentedon Jul 31, 2020
@StephenBrown2 Want to open an issue for retries so we can start discussing the API, and finer details of the expected behaviours? Even tho it's not strictly a 1.0 blocker, perhaps it's feasible it might still land in time for that.
Useful initial points to discuss:
requestsprovides for retries. (I think you need to mount an adapter in order to get retry support right?)requestsuses throughurllib3, when enabled without providing any finer-tuning details?urlilb3offer in it'sRetryconfig class?florimondmanca commentedon Jul 31, 2020
Also I think there’s lots of useful context and ideas already starting from #784 :-)
No adapter required - the idea was to loop around send_single_request() (I think?) in case of connection failures. The PR stopped at handling network errors only (so no retries on HTTP status errors or stuff like that) and I think there was a rationale behind that, but don’t have the exact thing off the top of my mind.
StephenBrown2 commentedon Jul 31, 2020
The original issue is #108 (gosh, over 900 Issues/PRs ago). I can try to summarize in a bit, but @florimondmanca is right, the interface is just a parameter to the client or requester, similar to the
Timeoutwe've got now. However, #778 had a good idea with aretry_flowmethod to overwrite, similar to theauth_flowmethod httpx also has now.lovelydinosaur commentedon Aug 7, 2020
Closing this one off, since I think everything we need to track is appropriately milestoned now.