Calling the framework using WSL using the following commands:
run -Dhttps.port=9001
After calling the url, the console prints this error:
Unsupported HTTP method: HTTP method too long (started with '╚╔ ᆰᆭ╚╚k{ヨ╝V'). Increase 'akka.http.server.parsing.max-method-length' to support HTTP methods with more characters.
I solved it myself. For other people: Try if it works with wget. If so try another browser.
We are getting this too. It works fine in Chrome, but not in Firefox, where we get a 400 response code. Each request has different gibberish:
'400 Bad Request': Unsupported HTTP method: HTTP method too long (started with 'kチニᄑ').
'400 Bad Request': Unsupported HTTP method: HTTP method too long (started with '£ナ2iᅭ')
'400 Bad Request': Unsupported HTTP method: HTTP method too long (started with '→テ2ᄅ')
etc.
We are getting this too. It works fine in Chrome, but not in Firefox, where we get a 400 response code.
Can you describe in detail what you are doing and what error you are getting?
Is this what you get when trying to access an HTTP endpoint with HTTPS?
Not in a lot of detail to be honest, as I'm a PHP developer! Our system connects to port 9000 with a POST request, but without even doing anything fancy, in chrome we get a 404 page for any fake endpoint, but in firefox we just get a 400. I'll come back once i've found the java guys in the office who actually made the thing! Cheers for the speedy response btw!
@raboof well spotted! In chrome it is definitely an unencrypted http connection, for some reason firefox is redirecting to https! That could be a configuration error on our part possibly, again I need to find the java guys responsible! If they are certain everything is cool with their code then I'll come back, but I guess you can keep this issue closed until then! :-) Cheers!
@delboy1978uk excellent! It could be your firefox has cached a redirect from http to https somehow? Anyway, good luck tracking this down! ;)
We could try to give at least better error messages in that case by using a heuristic for the HTTPS handshake? Or ... we could start promote t-shirts with ╚╔ ᆰᆭ╚ to raise awareness?
Or ... we could start promote t-shirts with ╚╔ ᆰᆭ╚ to raise awareness?
I’d love such t-shirt :O
--
Cheers,
Konrad 'ktoso http://kto.so' Malawski
Akka http://akka.io/ @ Lightbend http://lightbend.com/
On February 1, 2018 at 22:30:25, Johannes Rudolph ([email protected])
wrote:
We could try to give at least better error messages in that case by using a
heuristic for the HTTPS handshake? Or ... we could start promote t-shirts
with ╚╔ ᆰᆭ╚ to raise awareness?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/akka/akka-http/issues/1458#issuecomment-362266163, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHYk5-EyTyJM91A0MjEoo08qGmR4NYIks5tQbxwgaJpZM4PxUq7
.
Is it here where people should ask for ╚╔ ᆰᆭ╚ shirts?
It seems the original string wasn't HTTPS. I tried to reproduce the actual string but unfortunately I didn't find out what kind of protocol ╚╔ ᆰᆭ╚╚k{ヨ╝V would be :(
Hah, would be very interesting to find out, before we make tshirts with it ;-)
haha that is brilliant!
Even though this is fixed, we might consider logging the method only if it is printable or ASCII ... like Charset.forName("US-ASCII").newEncoder().canEncode(method) ... as otherwise the binary blob usually breaks console/logging ...
Even though this is fixed, we might consider logging the
methodonly if it is printable or ASCII ... likeCharset.forName("US-ASCII").newEncoder().canEncode(method)... as otherwise the binary blob usually breaks console/logging ...
Yeah, I'd be fine with a short hex dump of maybe the first 10 chars.
Most helpful comment
😉 https://www.spreadshirt.com/create-your-own?productType=812&appearance=648