I encountered this issue after visiting the RubyGems page for the latest version of the Adornable gem and clicking the "Documentation" link under "Links" in the sidebar.
I was taken to what should have been the documentation page on rubydoc.info, but it looked like this instead (Firefox):
And similar in Chrome:
Note that the address for this page was: https://www.rubydoc.info/gems/adornable/1.3.0, and it also happens at https://www.rubydoc.info/gems/adornable (no version specified in URL; latest version by default)
Investigation
Subsequent refreshes and hard-refreshes (without cache) did not fix the issue.
Looking at the Network tab in my browser's developer tools, I see that the actual response HTML is invalid. It is wrapped in [" + "]; i.e., the HTML is returned as a string at element 0 of a single-membered JSON array. This is returned no matter how many times I refresh/hard-refresh the page or use a different browser or use an incognito window.
The Cache-Control header in the response has a value of public, max-age=14400, for what it's worth, so it's probably cached server-side for at least four hours.
Now, if I remove the www. subdomain and go directly to https://rubydoc.info/gems/adornable/1.3.0 I see the following page (good/valid HTML):
The "latest version" page (no version specified in the URL) also looks good/valid when the www. subdomain is removed (i.e., https://rubydoc.info/gems/adornable).
Reproduction
I checked a few low-traffic gems using the rubydoc.info search to try to reproduce the issue, and was unsuccessful. I have a hypothesis that if www. is included in the first time a gem's documentation page is visited (and therefore built), then it will cache the invalid HTML document for some non-trivial amount of time.
To test that hypothesis, you would need to:
Create a new gem, or a new version of an existing gem, and do not include a documentation config option in the gemspec (so that it defaults to rubydoc.info on rubygems.org)
Publish it to rubygems.org with a gem build and a gem push
DO NOT look the gem up on rubydoc.info or attempt to visit the documentation page except by the following steps
Background
I encountered this issue after visiting the RubyGems page for the latest version of the Adornable gem and clicking the "Documentation" link under "Links" in the sidebar.
I was taken to what should have been the documentation page on rubydoc.info, but it looked like this instead (Firefox):
And similar in Chrome:
Note that the address for this page was:
https://www.rubydoc.info/gems/adornable/1.3.0, and it also happens athttps://www.rubydoc.info/gems/adornable(no version specified in URL; latest version by default)Investigation
Subsequent refreshes and hard-refreshes (without cache) did not fix the issue.
Looking at the Network tab in my browser's developer tools, I see that the actual response HTML is invalid. It is wrapped in
["+"]; i.e., the HTML is returned as a string at element 0 of a single-membered JSON array. This is returned no matter how many times I refresh/hard-refresh the page or use a different browser or use an incognito window.The
Cache-Controlheader in the response has a value ofpublic, max-age=14400, for what it's worth, so it's probably cached server-side for at least four hours.Now, if I remove the
www.subdomain and go directly tohttps://rubydoc.info/gems/adornable/1.3.0I see the following page (good/valid HTML):The "latest version" page (no version specified in the URL) also looks good/valid when the
www.subdomain is removed (i.e.,https://rubydoc.info/gems/adornable).Reproduction
I checked a few low-traffic gems using the rubydoc.info search to try to reproduce the issue, and was unsuccessful. I have a hypothesis that if
www.is included in the first time a gem's documentation page is visited (and therefore built), then it will cache the invalid HTML document for some non-trivial amount of time.To test that hypothesis, you would need to:
documentationconfig option in the gemspec (so that it defaults to rubydoc.info on rubygems.org)gem buildand agem push...which I will try to do myself if I have some time.
Related
I believe this recent issue (https://github.com/docmeta/rubydoc.info/issues/184) exhibits the same symptom(s) I described above. The author of that issue closed it because it had self-mitigated, but clearly this is an ongoing problem in some respect.