Skip to content
This repository has been archived by the owner on Mar 22, 2023. It is now read-only.

Add unsupported headers #1367

Merged
merged 17 commits into from
Jun 8, 2021
Merged

Conversation

kevo1ution
Copy link
Contributor

Changes proposed in this PR

  • We can configure added unsupported headers which will short circuit and waiter will respond with an error

Why are we making these changes?

  • We can easily add different waiter headers that are not available for on-the-fly requests

[:state server-name]
websocket-secure-request-acceptor-fn]
; If adding new middleware for websocket upgrade requests, consider adding the same middleware to
; process-request-wrapper-fn
(let [handler (-> #(ws/request-subprotocol-acceptor (:upgrade-request %) (:upgrade-response %))
(let [temp-fn (fn [handler]
Copy link
Contributor

Choose a reason for hiding this comment

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

Needs to be removed.

@@ -1547,6 +1548,7 @@
auth/wrap-auth-bypass
handler/wrap-https-redirect
pr/wrap-maintenance-mode
(pr/wrap-unsupported-waiter-headers unsupported-headers)
Copy link
Contributor

Choose a reason for hiding this comment

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

How do you feel about moving this to descriptor/compute-descriptor (after the headers/split-headers invocation)? I think that function should be responsible for disallowing certain headers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good idea, I agree. I'm going to confirm it has the same behavior for websockets because the compute-descriptor function will have called by the :default-websocket-handler-fn instead of :websocket-request-acceptor

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay the error needs to surface in the websocket-request-acceptor handler which doesn't call descriptor/compute-descriptor in its tree of function calls. I had to add a error handler and include this logic in the discover-service-parameters function

Copy link
Contributor

@shamsimam shamsimam Jun 8, 2021

Choose a reason for hiding this comment

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

How does websocket request acceptor decide on the service ID?

Misunderstood your comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The descriptor/compute-descriptor eventually gets called by the default-websocket-handler, but not the websocket-request-acceptor which is where we want to fail the websocket connection upgrade request

@kevo1ution kevo1ution force-pushed the disallow-certain-on-the-fly-headers branch from fd1afaa to c974e80 Compare June 8, 2021 15:05
waiter/integration/waiter/basic_test.clj Outdated Show resolved Hide resolved
waiter/src/waiter/service_description.clj Outdated Show resolved Hide resolved
waiter/src/waiter/service_description.clj Outdated Show resolved Hide resolved
Co-authored-by: Shams <shamsimam@users.noreply.github.com>
@kevo1ution kevo1ution merged commit 8fc1fd7 into master Jun 8, 2021
@kevo1ution kevo1ution deleted the disallow-certain-on-the-fly-headers branch June 8, 2021 16:19
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants