-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose connection metadata in HTTP::Server::Context #5784
Comments
I've looked at some other API's and I found a nice addition in Java's |
It should conceptually be on |
@RX14 Having it on There are separate |
Which is why I said more than a year ago now we shouldn't use the same class for client and server requests. We either should have 2 or 4 classes: |
#7610 finally added With I don't think there is currently any means to discover whether a request was made over TLS or not. This has probably more relevant use cases. For example, when the server has interfaces for both HTTP and HTTPS, a handler might restrict some behaviour depending on whether its encrypted or not (for example form submissions, login cookies etc.). This would be similar to the |
Nginx can pass a header with the schema used to connect. Of course this isn't something Crystal's HTTP Server can do for you. But if you need this functionality now, it is available by means of a reverse proxy like Nginx (which given the amount of testing in production, among other factors https://stackoverflow.com/a/50522656 (answer discusses Ruby and Puma, same concepts apply with Crystal), you should be using in front of Crystal's application server) |
Bumping this. A use case I have is for generating URLs to a given route, which could be an absolute URL including the scheme/hostname. I think ideally I would use the scheme of the original request, but alas I'm not able to determine that. |
As a follow up to my last comment, can someone confirm the way to determine if a request was EDIT: I went and checked a few diff frameworks handle getting the scheme/if request is over https:
I dont think Crystal exposes TLS connection info on the request. So in order to determine the scheme I guess I'd either have to assume |
With #5776 upcoming,
HTTP::Server
can listen on multiple networks sockets - and even without that, it would be useful for a handler to be able to access information about the network connection used to process.My initial idea was to expose the socket as
Context#socket
but that would also allow to take over the IO which should be avoided (there'sResponse#upgrade
for that).There really just needs to be access to metadata about the socket, for example
local_address
andremote_address
(note thatremote_address
is not particularly useful to identify the actual client's IP because of proxies and whatnot).I don't know if there would be any other useful data.
We could think about encapsulating the values in a struct like
Socket::Metadata
but I'm not sure it's worth adding another type for just two data points.A question is whether to expose it: on
Context
orResponse
. I'd say the most logical place would beContext
as it relates to both request and response. On the other hand, other network related features (such as the mentioned#upgrade
as well as#close
) are onResponse
.Another issue is how to implement it. It could either be just delegates to the
Socket
instance. this would be easy inReponse
because the network socket is already available internally as@io
. ForContext
it would either need access toResponse
's internal io or store a reference to the socket itself. A different solution would be to just copy the values to theContext
(orResponse
) instance.And the third question I'm not sure about, how this should behave when no network connection is involved (for example in specs that don't go through the network stack). Should it just return
nil
or a default value like the loopback address (but what would that be for Unix sockets?).The text was updated successfully, but these errors were encountered: