Cache and case in parameter Url

[DegrangeM]

Are you experiencing an issue with...

shields.io

🐞 Description

The cache remember the case in url, if one parameter is written with wrong case, it will break this parameter until cache expire (i assume this is a cache issue but I might be wrong).

Here an example:

• Open this URL : https://img.shields.io/badge/logo-BugBugBugBug-blue?logo=javascript&logocolor=red
  • Please note that in this url, the logoColor case is not good, the c is in lowercase instead of upper case.
• Then, open this url : https://img.shields.io/badge/logo-BugBugBugBug-blue?logo=javascript&logoColor=red
  • In this url, the case is good, but it redirect you to the url with the wrong case. You have no way to have this logo with a red color (exept waiting for cache to expire I assume).

edit : for some reason the bug doesn't happen if I make clickable link. So you now need to copy/paste Url.

🔗 Link to the badge

No response

💡 Possible Solution

No response

[chris48s]

OK, so I tried to reproduce this issue.

Tried it in firefox - works as expected.

Tried it with curl - works as expected.

Tried it in Chromium. If I load https://img.shields.io/badge/logo-BugBugBugBug-blue?logo=javascript&logocolor=red in one tab, and then open another tab and try and type https://img.shields.io/badge/logo-BugBugBugBug-blue?logo=javascript&logoColor=red in another tab, it seems to manually change the URL back to https://img.shields.io/badge/logo-BugBugBugBug-blue?logo=javascript&logocolor=red - its not even considering logocolor and logoColor the "same" URL for cache purposes. It just literally changes the URL in the address bar for me.

If you go back and try it, is this what you're actually seeing?

This seems like weird browser behaviour rather than anything on our side.

[calebcartwright]

This seems like weird browser behaviour rather than anything on our side.

I'd agree with this assessment and will add some content below that I think supports this (emphasis mine):

https://www.rfc-editor.org/rfc/rfc3986#section-6.2.2.1

For all URIs, the hexadecimal digits within a percent-encoding
triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore
should be normalized to use uppercase letters for the digits A-F.

When a URI uses components of the generic syntax, the component
syntax equivalence rules always apply; namely, that the scheme and
host are case-insensitive and therefore should be normalized to
lowercase. For example, the URI HTTP://www.EXAMPLE.com/ is
equivalent to http://www.example.com/. The other generic syntax
components are assumed to be case-sensitive unless specifically
defined otherwise by the scheme (see Section 6.2.3).

https://www.rfc-editor.org/rfc/rfc7230#section-2.7.3

Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the
algorithm defined in Section 6 of [RFC3986], using the defaults
described above for each scheme.

If the port is equal to the default port for a scheme, the normal
form is to omit the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. The scheme and host
are case-insensitive and normally provided in lowercase; all other
components are compared in a case-sensitive manner. Characters other
than those in the "reserved" set are equivalent to their
percent-encoded octets: the normal form is to not encode them (see
Sections 2.1 and 2.2 of [RFC3986]).

For example, the following three URIs are equivalent:

[http://example.com:80/~smith/home.html](http://example.com/~smith/home.html)
http://EXAMPLE.com/%7Esmith/home.html
[http://EXAMPLE.com:/%7esmith/home.html](http://example.com/%7esmith/home.html)

[DegrangeM]

Yes, it's seems it's a chromium issues, thanks for the analysis. I think we can close this issue ?

[calebcartwright]

agreed, thanks for reaching out!