Created
October 5, 2020 05:53
-
-
Save bagder/8de90fcb15031bb1b71c14848ad345ce to your computer and use it in GitHub Desktop.
fix for jfuller's test360
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| --- data/test360~ 2020-10-05 07:44:59.291501064 +0200 | |
| +++ data/test360 2020-10-05 07:51:34.882694526 +0200 | |
| @@ -44,7 +44,7 @@ | |
| CURL_ALTSVC_HTTP="yeah" | |
| </setenv> | |
| <command> | |
| ---http2 --alt-svc "log/altsvc-360" "http://%HOSTIP:%HTTPSPORT/360" "http://%HOSTIP:%HTTPSPORT/360" | |
| +--http2 --alt-svc "log/altsvc-360" "http://%HOSTIP:%HTTP2PORT/360" "http://%HOSTIP:%HTTP2PORT/360" | |
| </command> | |
| </client> |
It doesn't use HTTPS so HTTPSPORT is just wrong. If you want the HTTP/1 server to respond to the first request it should rather use HTTPPORT I believe.
so when I first tried this (some moons ago) I did something like
-k --alt-svc "log/altsvc-360" "https://%HOSTIP:%HTTPSPORT/360" "https://%HOSTIP:%HTTPSPORT/360
I was expecting alt-svc to make an entry (due to alt-svc header) ... which also does not work ... then I flailed about with the above and that also did not work - feel like I am missing some important context either in test framework or my understanding.
HTTPS in there works for me. At least if the certificate issue is dealt with.
right and thats where the issue is/was ! thank you for helping me isolate !
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
interesting, my expectation was that my alt-svc would route from HTTPSPORT to HTTP2PORT and set entry as so in alt-svc cache ... perhaps my expectation is wrong