nginx ingress with prefix path remove trailing slash

Viewed 924

This is how I define access to my service with ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: client-ingress
spec:
  rules:
    - host: gemini.demo
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: client-service
                port:
                  number: 80

Basically it works according to my needs except a small detail. In the browser the prefix slash remains behind domain if there is no following path.

So when I go to http://gemini.demo I will get http://gemini.demo/

How can I get rid of the trailing slash at the end of domain?

1 Answers

According to RFC 2616 (HTTP/1.1), section 3.2.2, the URLs http://www.example.com and http://www.example.com/ are equivalent, and HTTP clients must normalize the former to the latter before sending the request to the server:

"If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2)."

where section 5.1.2 says:

"Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as "/" (the server root)."

RFC 3986 (URI Generic Syntax) confirms this in section 6.2.3, Scheme-Based Normalization, noting that:

"For example, because the "http" scheme makes use of an authority component, has a default port of "80", and defines an empty path to be equivalent to "/", the following four URIs are equivalent:

http://example.com
http://example.com/
http://example.com:/
http://example.com:80/

In general, a URI that uses the generic syntax for authority with an empty path should be normalized to a path of "/". Likewise, an explicit ":port", for which the port is empty or the default for the scheme, is equivalent to one where the port and its ":" delimiter are elided and thus should be removed by scheme-based normalization. For example, the second URI above is the normal form for the "http" scheme."

Technically, the normalization described in RFC 3986 section 6.2.3 is optional for implementations that e.g. merely index URLs, although RFC 2616 makes it mandatory for clients wishing to actually send HTTP requests. Still, given that the standard permits such normalization, and given that search engines generally don't want to deliberately add duplicates to their index, one can be reasonably sure that just about all search engines will be normalizing all those URLs to be the same.

Thus, it makes no difference to either browsers or search engines whether you use http://www.example.com or http://www.example.com/. They're equivalent.

Going forward with this, it will be helpful if you provide more details on live scenarios or testing which you are performing.

Related