Skip to content

Conversation

@adamkaplan
Copy link

The sensible defaults are http and https for backwards compatibility

There are additional protocol schemes which utilize vanilla HTTP/S, but enable additional functionality. The specific example I am submitting this to fix is websockets.

This is a long explanation for a tiny change:

Why is a change needed?

The scheme string is required to compute the OAuth 1.0a signature. Unfortunately the scheme is not transmitted in HTTP/1.1 requests. The only information known is whether TLS was used to secure the connection (request.encrypted). Currently this project assumes https if encryption was used, or http otherwise. In order to support additional standardized or custom schemes, some changes were needed.

Why should Websocket support exist in an HTTP library!?

Websockets is HTTP as much as HTTPS is HTTP. In the case of HTTPS, the TLS steps happen up front, and is followed by a vanilla HTTP message structure. In the case of Websockets, it's pure HTTP (or HTTPS) up front, and then Websockets afterward. Both of these just build on HTTP, so it's all the same!

The sensible defaults are http and https for backwards compatibility
@adamkaplan
Copy link
Author

The passport project appears to be on life support w/o enough contributors to merge PRs :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants