feat: bump gwapi to v0.7.1

[Xunzhuo]

What type of PR is this?

feat: bump gwapi to v0.7.1

What this PR does / why we need it:

bump gwapi to v0.7.1

[codecov]

Codecov Report

Merging #1478 (56c0cf9) into main (0775da1) will decrease coverage by 0.13%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1478      +/-   ##
==========================================
- Coverage   61.77%   61.65%   -0.13%     
==========================================
  Files          81       81              
  Lines       12130    12131       +1     
==========================================
- Hits         7493     7479      -14     
- Misses       4172     4184      +12     
- Partials      465      468       +3     

Impacted Files	Coverage Δ
internal/xds/translator/translator.go	80.76% <100.00%> (+0.09%)	⬆️

... and 2 files with indirect coverage changes

[arkodg]

looks like IgnorePortInHostMatching https://pkg.go.dev/github.com/envoyproxy/go-control-plane/envoy/config/route/v3#RouteConfiguration needs to be set instead of stripping the port from the host (i.e. revert #1389)
thanks to @sunjayBhatia & @howardjohn's triage in kubernetes-sigs/gateway-api#2091

[Xunzhuo]

@arkodg so we need to revert #1389 ?

[arkodg]

yah @Xunzhuo , we'll need to

• revert feat: Strip port from host if user specifies a Hostname #1389
• add IgnorePortInHostMatching in every RouteConfiguration
• then bump to v0.7.1

can be done in this PR or we can raise issues for each

[arkodg]

looks like HTTPRouteRequestMirror will need to be skipped, can you also raise a issue to track enabling it once the issue has been triaged and fixed

[arkodg]

LGTM, thanks for also improving dev velocity by introducing make testdata

[jackkleeman]

I think IgnorePortInHostMatching won't work for :authority exact/suffix header matching, which is set up when we have hosts defined in httproutes and not in listeners

[howardjohn]

I think IgnorePortInHostMatching won't work for :authority exact/suffix header matching, which is set up when we have hosts defined in httproutes and not in listeners

Istio handles this by matching in domains rather than a :authority header match

[jackkleeman]

ok, maybe i can pr a fix to use that approach for the routes instead of :authority

[jackkleeman]

hm, the problem here is that domains is listener-scoped, but i am talking about the case where httproute is more specific on hostname than listeners - in that case we are currently creating a authority header match. maybe that header match just needs to be more port agnostic

[howardjohn]

I mean here: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-virtualhost

…

On Thu, Jul 20, 2023 at 9:15 AM Jack Kleeman ***@***.***> wrote: hm, the problem here is that domains is listener-scoped, but i am talking about the case where httproute is more specific on hostname than listeners - in that case we are currently creating a authority header match. maybe that header match just needs to be more port agnostic — Reply to this email directly, view it on GitHub <#1478 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGXKXRPPH6YUAONPOBULXRFKTXANCNFSM6AAAAAAY2K6R7A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jackkleeman]

no indeed, but doesnt virtualhost map to gateway listener?

[howardjohn]

Listener: match whatever
Routes:

virtual_hosts:
- domains: [*.example.com]
- domains: [bar.example.com]

[jackkleeman]

sure, but envoy/gateway currently creates only 1 virtual host per HttpListener as defined in the gateway object:

// Allocate virtual host for this httpListener.
		// 1:1 between IR HTTPListener and xDS VirtualHost
		vHost := &routev3.VirtualHost{
			Name:    httpListener.Name,
			Domains: httpListener.Hostnames,
		}

So we would need to change that to be 1-to-many irght?

[howardjohn]

Yes

[howardjohn]

TBH I did not realize I was commenting in envoyproxy/gateway repo 🙂

[jackkleeman]

hah! no worries

[arkodg]

hey @jackkleeman thanks for surfacing this issue, created a newer issue to track this limitation #1687