Caddy: Add placeholder to indicate when QUIC transport is used

Created on 4 Aug 2017  Â·  12Comments  Â·  Source: caddyserver/caddy

Hi

Is it possible to add a placeholder to allow recording of usage of QUIC in e.g. access logs please? Ideally, including (or as a separate placeholder) the QUIC version.

I'm currently trying to determine why QUIC doesn't work on my website and this would be useful. Currently, since QUIC is the Google flavour (h2 over QUIC), all i see is "HTTP/2" in the {protocol} placeholder.

Cheers

feature request help wanted

Most helpful comment

I think the probability for breaking people by changing the Proto is low, especially if they are brave enough to try QUIC ;)

I'm inclined to go with Chrome's format but capitalized (to fit more into Go's style), i.e. "HTTP/2+QUIC/37". The version number might be an issue though: It's just 4 bytes under the hood and currently readable as ASCII "37" by "coincidence". So, maybe we should just put it there in hex from the start.

All 12 comments

@slightfoot Would there be a case for adding quic to the output of the {protocol} placeholder rather than a seperate {quic} placeholder?

@tobya I'm not sure that would be correct. It is still HTTP/2.0 but going over QUIC transport protocol. Perhaps we need a newer generic key for transport-proto. This could then be used for CGI, FCGI and so on.

@neilstuartcraig This is just me playing about, this change might not make it to release.

@mholt @abiosoft The detection method causes a go vet issue because s.Server has a lock that's duplicated. Although I could replace that lock. This whole thing seems a horrible idea. Do you have any other ideas as to how we might determine if a request is being transported over QUIC.

@lucas-clemente Your thoughts would be appreciated.

Might be a bit crude but what if you detect udp- since no other usage (AFAIK) in caddy is udp.

Sent from my iPhone

On 6 Aug 2017, at 13:21, Simon Lightfoot notifications@github.com wrote:

@mholt @abiosoft The detection method causes a go vet issue because s.Server has a lock that's duplicated. Although I could replace that lock. This whole thing seems a horrible idea. Do you have any other ideas as to how we might determine if a request is being transported over QUIC.

@lucas-clemente Your thoughts would be appreciated.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

+@marten-seemann

There are a couple of ways we could pass the information on to Caddy. We currently set the Protocol field in the request to "HTTP/2.0", I'm guessing this is what Caddy uses for {protocol}? We can try to set that to something like "QUIC" or "QUIC/", WDYT?

If the {proto} placeholder was changed to be e.g. "quic+http/2" (like Chrome does in dev tools) then that'd work for me personally. It'd be great to know the quic version too if possible.

Chrome 60 uses this format: http/2+quic/37

Although we could match chrome and edit the protocol field. My concern is that golang http library doesn't expect that format, as well as other libraries.

If we were to modify the field usage then it might be better to go with something like HTTP/2.0 QUIC/37. This then matches the previous HTTP/2.0 with the addition of space separated tokens for other protocols.

Any method is fine from my perspective, i'd just add a field to my access log format :-)

I think the probability for breaking people by changing the Proto is low, especially if they are brave enough to try QUIC ;)

I'm inclined to go with Chrome's format but capitalized (to fit more into Go's style), i.e. "HTTP/2+QUIC/37". The version number might be an issue though: It's just 4 bytes under the hood and currently readable as ASCII "37" by "coincidence". So, maybe we should just put it there in hex from the start.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

PhilmacFLy picture PhilmacFLy  Â·  3Comments

dafanasiev picture dafanasiev  Â·  3Comments

crvv picture crvv  Â·  3Comments

lorddaedra picture lorddaedra  Â·  3Comments

billop picture billop  Â·  3Comments