Handling repeated query params in query string

[pleshakov]

Hello folks! For a query string ?a=1&a=2 and the following matches in an HTTPRoute:
(1)

queryParams:
- name: a
  value: "1"

(2)

queryParams:
- name: a
  value: "2"

Should (1) match?
Should (2) match?

I wonder what the expected behavior is.

Notes:

• the confirmance tests do not test for that case --

  gateway-api/conformance/tests/httproute-query-param-matching.go

  Lines 47 to 80 in 5af4606

  	Request: http.Request{Path: "/?animal=whale"},
  	Backend: "infra-backend-v1",
  	Namespace: ns,
  	}, {
  	Request: http.Request{Path: "/?animal=dolphin"},
  	Backend: "infra-backend-v2",
  	Namespace: ns,
  	}, {
  	Request: http.Request{Path: "/?animal=dolphin&color=blue"},
  	Backend: "infra-backend-v3",
  	Namespace: ns,
  	}, {
  	Request: http.Request{Path: "/?ANIMAL=Whale"},
  	Backend: "infra-backend-v3",
  	Namespace: ns,
  	}, {
  	Request: http.Request{Path: "/?animal=whale&otherparam=irrelevant"},
  	Backend: "infra-backend-v1",
  	Namespace: ns,
  	}, {
  	Request: http.Request{Path: "/?animal=dolphin&color=yellow"},
  	Backend: "infra-backend-v2",
  	Namespace: ns,
  	}, {
  	Request: http.Request{Path: "/?color=blue"},
  	StatusCode: 404,
  	}, {
  	Request: http.Request{Path: "/?animal=dog"},
  	StatusCode: 404,
  	}, {
  	Request: http.Request{Path: "/?animal=whaledolphin"},
  	StatusCode: 404,
  	}, {
  	Request: http.Request{Path: "/"},

• the query param doc doesn't seem to describe that case --

  gateway-api/apis/v1beta1/httproute_types.go

  Line 408 in 5af4606

  type HTTPQueryParamMatch struct {

Cheers

[shaneutt]

This reminds me a lot of #1225 which was recently updated. The intention there was to document that only the first should match. Is this helpful?

[pleshakov]

#1225 and #1230 are about multiple same query params in a match in an HTTPRoute, rather than multiple same query params in the query string of a request (that's how I'm interpreting them)

[sunjayBhatia]

your actual proxy's handling of the query string may differ since it isn't really defined in an HTTP RFC, in Contour's case since Envoy is the actual proxy, the first occurrence of the query parameter will be considered to match against so for the given example only 1 would match that request, if the request had ?a=2&a=1, then 2 would match that request

[pleshakov]

I wonder if it makes sense to document that data planes might handle that case differently.

In the case of NGINX, its behavior is similar to Envoy - it will use the value of the first occurrence. However, by default it cannot distinguish between cases (A and a are the same). At the same time, there are ways to work around that case-insensitivity limitation and also to inspect all values of a parameter, not only the first occurrence.

[robscott]

x-ref: https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1beta1/httproute_types.go#L370-L371

[robscott]

where possible, we recommend matching the first specified query parameter.

[youngnick]

Thanks @pleshakov for opening #1271, which will cover the work to resolve this issue. I'll lock this conversation until we figure out a better way to handle resolved conversations.