HTTP version of requests and TLS #4

Closed
opened 2024-10-27 16:39:28 +00:00 by 0xEAB · 2 comments

Currently, the ServerHttpRequest struct tracks the HTTP version of the request.
As-is, it cannot properly do so for v1.0 and v0.9 requests.

Furthermore, lacks the option to track whether the requested originated from a secure connection (TLS as in HTTPS) in cases where this cannot be inferred from the used HTTP version.

Some web applications might want to make use of this information. While I do agree that there’s a misuse potential (e.g. URL building for links), there are valid use cases as well.

Currently, the `ServerHttpRequest` struct tracks [the HTTP version of the request](https://git.andrewlalis.com/Handy-Http/primitives/src/commit/23c74f82bedf662d3d6f8f2aed159a270f5a782d/source/handy_http_primitives/request.d#L15). As-is, it cannot properly do so for v1.0 and v0.9 requests. Furthermore, lacks the option to track whether the requested originated from a secure connection (TLS as in HTTPS) in cases where this cannot be inferred from the used HTTP version. Some web applications might want to make use of this information. While I do agree that there’s a misuse potential (e.g. URL building for links), there are [valid use cases](https://docs.nextcloud.com/server/29/admin_manual/configuration_server/security_setup_warnings.html#you-are-accessing-this-site-via-http) as well.
Author

As-is, it cannot properly do so for v1.0 and v0.9 requests.

As servers usually reply to such with v1.1 responses anyway, I guess it would be sufficient to rename V1_1 to V1 and document that it includes the whole version span of classic HTTP protocols.

> As-is, it cannot properly do so for v1.0 and v0.9 requests. As servers usually reply to such with v1.1 responses anyway, I guess it would be sufficient to rename `V1_1` to `V1` and document that it includes the whole version span of classic HTTP protocols.
Owner

Yep, makes sense. I've renamed it to V1, and added some documentation text to explain the scope of each version.

Yep, makes sense. I've renamed it to `V1`, and added some documentation text to explain the scope of each version.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Handy-Http/primitives#4
No description provided.