Skip to content
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.

Sign up for GitHub

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

Add "HTTP 464 error with AWS" to the FAQ #67

Merged
merged 5 commits into from
Nov 3, 2023
Merged

Add "HTTP 464 error with AWS" to the FAQ #67

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1e1916d
Add "HTTP 464 error with AWS" to the FAQ
timostamm Oct 9, 2023
2931ae1
Update docs/faq.md
timostamm Oct 10, 2023
edc82e0
Merge remote-tracking branch 'origin/main' into tstamm/add-aws-faq
timostamm Nov 1, 2023
dab4553
Clarify
timostamm Nov 1, 2023
605b897
grammar fix
timostamm Nov 1, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions docs/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -171,7 +171,23 @@ mappings for your backend services. You can work around this problem using the
`cluster_tag` property, as described in
[emissary-ingress/emissary#3112](https://github.com/emissary-ingress/emissary/issues/3112).

### HTTP 464 error with AWS

If you're using the [Application Load Balancer support for gRPC][alp-aws-grpc],
timostamm marked this conversation as resolved.
Show resolved Hide resolved
you will likely see an HTTP error response with code 464 for a Connect `GET`
request, or for a web browser making a CORS preflight `OPTIONS` request.
akshayjshah marked this conversation as resolved.
Show resolved Hide resolved

If you only need the Connect protocol, you can simply change your target group
to HTTP/2.

If you need both the Connect and gRPC protocols, you can use two target groups:
Route HTTP GET requests and anything with the `application/proto`, `application/json`,
`application/connect+proto`, or `application/connect+json` Content-Types to the
HTTP/2 target group. Route anything else to the gRPC target group.
Copy link
Member

@akshayjshah akshayjshah Oct 10, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

I'm not sure how to keep the text short, but I found this explanation a little misleading. Even if the user needs support for gRPC, they can continue to use an HTTP/2 target group - as far as I know, their RPCs will work just fine. However, they'll give up support for the gRPC-specific add-on features that gRPC target groups provide.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good call. I expanded it to clarify.


timostamm marked this conversation as resolved.
Show resolved Hide resolved

[remote packages]: https://buf.build/docs/bsr/remote-packages/overview/
[remote plugins]: https://buf.build/docs/bsr/remote-plugins/overview/
[twirp-protocol]: https://github.com/twitchtv/twirp/blob/main/PROTOCOL.md
[whatwg-streams-issue]: https://github.com/whatwg/fetch/issues/1438
[alp-aws-grpc]: https://aws.amazon.com/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/