On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes <t...@tomforb.es> wrote: > I’m a stats nerd, and I think I’m not alone on this list in that respect, > would it be possible to share some more numbers after a week of usage? I > would be interested in the total bandwidth used/saved, the global > distribution of requests and the average requests per second. If I remember > correctly fastly has a fantastic live dashboard with all of this info. >
For static, I think we'll end up using just under 300 GB a month, or about a quarter of the total bandwidth served by this particular server (which also handles most other djangoproject.com subdomains). I'll see if I can collect some slightly more interesting numbers after a week or two. I’m not entirely clear on the HTTP/2 issue, does Fastly not terminate these > and forward on http 1.1 requests? Could you elaborate a bit? > HTTP/2 supports connection coalescing <https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/>, where the browser (with varying degrees of aggressiveness, depending on the manufacturer) may reuse existing connections for different subdomains. In our case, Fastly originally provisioned a wildcard SSL cert ('*. djangoproject.com'), so *we think* that some versions of Firefox were reusing HTTP/2 connections originally established for static.djangoproject.com for requests to www.djangoproject.com, *even though* there was no overlap in IPs for the two domains. In the browser (courtesy of Mariusz) it looked like this: [image: Screenshot_20190320_113825.png] Clicking on the cert icon showed the wildcard cert from Fastly, not our Let's Encrypt cert, as well. In other words, it appeared Firefox was ignoring DNS for www.djangoproject.com and assumed that it could send those requests to static.djangoproject.com instead, simply because the server responded with an SSL certificate that matched www.djangoproject.com. I.e., it appeared to be *even more aggressive* than described under "The Firefox way" in the link above. I find this explanation entirely dissatisfying (if not altogether frightening), so part of me hopes I've got it wrong. :-\ In any case, after requesting that Fastly de-provision the wildcard cert and include only the specific domains we needed, the issue went away. There is an HTTP status code (421) that can be used to tell the browser it's made such an error, so I believe we also could have solved this by setting up a catchall service in Fastly to return HTTP 421 for any requests received on subdomains we weren't expecting. But avoiding the spurious requests to begin with seemed like a better solution, and provisioning certs only for the domains we need is cleaner to begin with and seems to have fixed the problem. I was never able to reproduce this in Firefox myself, but I did see evidence of it occurring insofar as we *also* started getting a very small number of requests to the '*docs*.djangoproject.com' service in Fastly after changing the DNS for '*static*.djangoproject.com.' Of course, no one would have noticed these because the requests returned successfully, but they should not have been going through Fastly (until the DNS was changed for 'docs', of course). Mariusz may be able to add something about the when/how he saw this; I do think it was fairly intermittent. Anyways, I'm pretty sure this would have gone undiagnosed for weeks if not months if he had not noticed and alerted us to the issue (causing all sorts of frustration and confusion in the meantime), so thank you again, Mariusz! Cheers, Tobias -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKREk0NZx93DMxOJdACO%2BHgSjGdoTLVuOLUHY3nFBgHTjg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
