Re: missing files because versioning?

Hi

I just noticed that opening www.postgresql.org under Chromium's DevTools
mode shows these three errors in the console:

DevTools failed to load source map: Could not load content for /media/js/popper.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load source map: Could not load content for /media/css/bootstrap.min.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load source map: Could not load content for /media/js/bootstrap.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

It appears that we do have these files under /media/, but with version
numbers embedded in their names. Does this mean that we're missing a
symlink, or perhaps a redirect rule?

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

On 3/8/23 2:08 PM, Alvaro Herrera wrote:
> Hi
>
> I just noticed that opening www.postgresql.org under Chromium's DevTools
> mode shows these three errors in the console:
>
> DevTools failed to load source map: Could not load content for /media/js/popper.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
> DevTools failed to load source map: Could not load content for /media/css/bootstrap.min.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
> DevTools failed to load source map: Could not load content for /media/js/bootstrap.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
>
> It appears that we do have these files under /media/, but with version
> numbers embedded in their names. Does this mean that we're missing a
> symlink, or perhaps a redirect rule?

These are used for debugging and the errors only show up if you load the
console. We can silence the error that removes the line that tries to
load the map files, or you can disable it in your local console i.e.
uncheck "enable source map files".

I have a patch ready that disables the actual load -- if you see an
unnecessary amount of 404 traffic to the web servers, I say we just do that.

Jonathan

On Thu, Mar 9, 2023, 02:27 Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:

> On 3/8/23 2:08 PM, Alvaro Herrera wrote:
> > Hi
> >
> > I just noticed that opening www.postgresql.org under Chromium's DevTools
> > mode shows these three errors in the console:
> >
> > DevTools failed to load source map: Could not load content for
> /media/js/popper.min.js.map: HTTP error: status
> code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
> > DevTools failed to load source map: Could not load content for
> /media/css/bootstrap.min.css.map: HTTP error:
> status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
> > DevTools failed to load source map: Could not load content for
> /media/js/bootstrap.min.js.map: HTTP error:
> status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
> >
> > It appears that we do have these files under /media/, but with version
> > numbers embedded in their names. Does this mean that we're missing a
> > symlink, or perhaps a redirect rule?
>
> These are used for debugging and the errors only show up if you load the
> console. We can silence the error that removes the line that tries to
> load the map files, or you can disable it in your local console i.e.
> uncheck "enable source map files".
>
> I have a patch ready that disables the actual load -- if you see an
> unnecessary amount of 404 traffic to the web servers, I say we just do
> that.
>

By definition it's unnecessary given we don't use it :-) it's not much
traffic on the server side though, but it certainly seems like something
worth optimizing for client side improvements if it's easy enough to do. At
least unless it turns out to be ugly or invasive against something else.

So it sounds like completing that patch is worthwhile.

/Magnus

>

On 3/22/23 10:17 AM, Magnus Hagander wrote:

> By definition it's unnecessary given we don't use it :-) it's not much
> traffic on the server side though, but it certainly seems like something
> worth optimizing for client side improvements if it's easy enough to do.
> At least unless it turns out to be ugly or invasive against something else.
>
> So it sounds like completing that patch is worthwhile.

I have it ready to go -- it's just removing:

"/*# sourceMappingURL=bootstrap.css.map */"

and the like from the minified files. I haven't posted it because it's a
1.5MB diff for a 3 line change (yay minified code).

But if there are no objections, I can push it.

Thanks,

Jonathan

On Wed, Mar 22, 2023 at 3:24 PM Jonathan S. Katz <jkatz(at)postgresql(dot)org>
wrote:

> On 3/22/23 10:17 AM, Magnus Hagander wrote:
>
> > By definition it's unnecessary given we don't use it :-) it's not much
> > traffic on the server side though, but it certainly seems like something
> > worth optimizing for client side improvements if it's easy enough to do.
> > At least unless it turns out to be ugly or invasive against something
> else.
> >
> > So it sounds like completing that patch is worthwhile.
>
> I have it ready to go -- it's just removing:
>
> "/*# sourceMappingURL=bootstrap.css.map */"
>
> and the like from the minified files. I haven't posted it because it's a
> 1.5MB diff for a 3 line change (yay minified code).
>
> But if there are no objections, I can push it.
>
>
Hmm. So it requires actually modifying the upstream import, that makes it a
lot more annoying for future imports etc. I don't like that idea at all.

Maybe the better option then is to just migrate over to using
assets.postgresql.org to increase the cache hits on them, stick the proper
map file in there, and rely on 304s.

//Magnus

On 3/24/23 8:10 AM, Magnus Hagander wrote:

> Maybe the better option then is to just migrate over to using
> assets.postgresql.org <http://assets.postgresql.org> to increase the
> cache hits on them, stick the proper map file in there, and rely on 304s.

That sounds like a better idea.

Jonathan