This code was required because we messed-up in the past regarding
caching headers. This is not required anymore because the caching set
has expired, so no well behaving user-agent should have remains.
This represents something like 240k requests to the backend (not the
cache) over two weeks. Server load was minimal because generating those
responses is really fast.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Important changes that should make reading the diff easier:
* Script now only works on line numbers. Elements are queried when
necessary
* handleLineRange was refactored into functions that only validate and
return line number(s), it's now the callers responsibility to
highlight the range
The current order for displaying references is:
- [definitions] prototype, label, typedef, variable, struct, member,
function
- documentation
- references
This order is not very practical when you are searching for information
about a symbol, as you often want to know if the symbol is documented.
By inverting the order and displaying the documentation first, the user
experience may be improved for finding the documentation. This should not
significantly change the UX for definitions, as there are already many
definitions, and you already have to search for what you want.
Avoid many tiny requests. The issue is that browsers have a limited
amount of concurrent requests they can make. We do 19 for
loading /linux/v6.11.6/source. Reduce that to 14.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Pygments 2.12.0 slightly changed the order of HTML elements which
makes line numbers look weird with current CSS styles.
Quoting changelog:
> When linenos=table is used, the <table> itself is now wrapped
> with a <div class="highlight"> tag instead of placing it
> inside the <td class="code"> cell (#632.) With this change,
> the output matches the documented behavior.
https://pygments.org/docs/changelog/#version-2-12-0
Related issue: https://github.com/pygments/pygments/issues/632
This commit aims to fix this by further restricting CSS selectors
that selected everything under .highlight to only select source code
related elements - descendants of .code in the new layout.
This was also tested on Pygemnts 2.14.0, version currently packaged
for Debian Bookworm
https://packages.debian.org/bookworm/armel/python3-pygments
This is NOT being served by Elixir backend. The HTTP server in front
must serve it. Commit robots.txt to store the file somewhere.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
favicon.ico being served is not dependent on Elixir's configuration, but
on the front-facing server. Its config must be updated to serve the
favicon; this is why favicon.ico used to not be commited into the
repo.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Fixes the following bug:
1. Make sure show-menu == true
2. Open page in mobile mode
3. Reisze to widescreen
Sidebar will be hidden until page is reloaded.
Backwards compatibility for browsers without svg support (in this
version) causes the logo to unnecessarily flicker on navigation.
According to caniuse.com SVG in img elements is supported in browsers
used by 97.85% of users. https://caniuse.com/svg-img
Firefox introduced support in 2011, Chrome in 2013, Safari in 2015.
This parameter makes the server return a response with raw file
contents and headers that cause the browser to show a 'save as' dialog.
Regarding Content-Security-Policy:
https://www.w3.org/TR/CSP2/#sandbox-usage
> For example, a message board or email system might provide downloads of
> arbitrary attachments provided by other users. Attacks that rely on tricking
> a client into rendering one of these attachments could be mitigated by
> requesting that resources only be rendered in a very restrictive sandbox.
> Sending the sandbox directive with an empty value establishes such an
> environment:
>
> Content-Security-Policy: sandbox
https://www.w3.org/TR/CSP2/#directive-default-src
> Given this behavior, one good way of building a policy for a site would be to
> begin with a default-src of 'none', and to build up a policy from there that
> contains only those resource types which are actually in use for the page
> you’d like to protect. If you don’t use webfonts, for instance, there’s no
> reason to specify a source list for font-src; specifying only those resource
> types a page uses ensures that the possible attack surface for that page
> remains as small as possible.
https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html#defense-in-depth
> A strong CSP provides an effective second layer of protection against various
> types of vulnerabilities, especially XSS. Although CSP doesn't prevent web
> applications from containing vulnerabilities, it can make those
> vulnerabilities significantly more difficult for an attacker to exploit.
The idea is to prevent the browser from loading any external resources, if it
turned out it's possible to trick it into interpreting a file as HTML.
