Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

hawkw
Copy link
Contributor

@hawkw hawkw commented Aug 31, 2017

Previously, when a HTTP/2 router received a HTTP/1 request, a ClassCastException was thrown, resulting in a "strange" stack trace (#1472).

I've added a line to match these exceptions & log a more meaningful warning.

Tested this by curling the H2 router started with ./sbt linkerd-examples/h2:run. While sending a request to the router's port with curl used to produce:

I 0831 21:34:14.309 UTC THREAD80: serving h2 on localhost/127.0.0.1:4142
I 0831 21:34:14.370 UTC THREAD80: initialized
E 0831 21:34:41.961 UTC THREAD95: [S L:/127.0.0.1:4142 R:/127.0.0.1:55072] dispatcher failed
java.lang.ClassCastException: Transport.cast failed. Expected type io.netty.handler.codec.http2.Http2Frame but found io.netty.handler.codec.http.DefaultHttpRequest

now it produces:

I 0831 22:03:50.611 UTC THREAD125: serving h2 on localhost/127.0.0.1:4142
I 0831 22:03:50.634 UTC THREAD125: initialized
W 0831 22:04:02.467 UTC THREAD138: [S L:/127.0.0.1:4142 R:/127.0.0.1:54985] HTTP/2 router could not handle HTTP/1 request!

@hawkw hawkw added the trivial label Aug 31, 2017
@hawkw hawkw added this to the 1.2.0 milestone Aug 31, 2017
@hawkw hawkw self-assigned this Aug 31, 2017
@hawkw hawkw requested review from adleong, klingerf and pcalcado August 31, 2017 22:07
@hawkw
Copy link
Contributor Author

hawkw commented Aug 31, 2017

Alternative Solutions

  • Ideally, we'd like to actually perform a protocol upgrade negotiation (see H1 upgrade and downgrade #841), but that isn't supported yet.
  • I suggested sending the H1 client either a 429 ("upgrade required") error or a 400 error with a message stating that the H2 router can't handle H1 requests at this time, but @adleong said he'd prefer not to see H2 routers returning any H1 responses...


// if we attempted to cast a Http2Frame as a H1 frame, log a message & kill the
// connection.
case Throw(e: ClassCastException) if e.getMessage == H1RequestError =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried about this being quite brittle but... I can't really see a better way

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps remove the message equality check and make the log more generic? "HTTP/2 router could not handle non-HTTP/2 request!"? WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered that, but it seemed unwise to assume all ClassCastExceptions were due to a mismatched request protocol. If a ClassCastException was thrown for some other reason, logging the protocol error message would obscure that failure...

What about a test that the message contains "Transport.cast failed."?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Member

@adleong adleong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⭐ 🔨

@hawkw hawkw merged commit ec612f6 into master Sep 1, 2017
pcalcado pushed a commit that referenced this pull request Sep 6, 2017
Previously, when a HTTP/2 router received a request in a non-HTTP/2 protocol, a `ClassCastException` was thrown, resulting in a stack trace that was not very user-friendly and did not accurately describe what had occurred.

I've added a line to match these exceptions & log a more meaningful warning.

Tested this by `curl`ing the H2 router started with `./sbt linkerd-examples/h2:run`.

Closes #1472.
@hawkw hawkw mentioned this pull request Sep 7, 2017
hawkw added a commit that referenced this pull request Sep 7, 2017
## 1.2.0 2017-09-07

* **Breaking Change**: `io.l5d.mesh`, `io.l5d.thriftNameInterpreter`, linkerd
  admin, and namerd admin now serve on 127.0.0.1 by default (instead of
  0.0.0.0).
* **Breaking Change**: Removed support for PKCS#1-formatted keys. PKCS#1 formatted keys must be converted to PKCS#8 format.
* Added experimental `io.l5d.dnssrv` namer for DNS SRV records (#1611)
* Kubernetes
  * Added an experimental `io.l5d.k8s.configMap` interpreter for reading dtabs from a Kubernetes ConfigMap (#1603). This interpreter will respond to changes in the ConfigMap, allowing for dynamic dtab updates without the need to run Namerd.
  * Made ingress controller's ingress class annotation configurable (#1584).
  * Fixed an issue where Linkerd would continue routing traffic to endpoints of a service after that service was removed (#1622).
  * Major refactoring and performance improvements to `io.l5d.k8s` and `io.l5d.k8s.ns` namers (#1603).
  * Ingress controller now checks all available ingress resources before using a default backend (#1607).
  * Ingress controller now correctly routes requests with host headers that contain ports (#1607).
* HTTP/2
  * Fixed an issue where long-running H2 streams would eventually hang (#1598).
  * Fixed a memory leak on long-running H2 streams (#1598)
  * Added a user-friendly error message when a HTTP/2 router receives a HTTP/1 request (#1618)
* HTTP/1
  * Removed spurious `ReaderDiscarded` exception logged on HTTP/1 retries (#1609)
* Consul
  * Added support for querying Consul by specific service health states (#1601)
  * Consul namers and Dtab store now fall back to a last known good state on Consul observation errors (#1597)
  * Improved log messages for Consul observation errors (#1597)
* TLS
  * Removed support for PKCS#1 keys (#1590)
  * Added validation to prevent incompatible `disableValidation: true` and `clientAuth` settings in TLS client configurations (#1621)
* Changed `io.l5d.mesh`, `io.l5d.thriftNameInterpreter`, linkerd
  admin, and namerd admin to serve on 127.0.0.1 by default (instead of
  0.0.0.0) (#1366)
* Deprecated `io.l5d.statsd` telemeter.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants