How long for Google to re-index to HTTPS?

[Sally Stitts]

I completed ALL my HTTPS prep tasks (link changes and new sitemap) on July 6, 2017, and 301ed everything.
Today, Aug. 16, Google has switched about 50% of my 450 pages to HTTPS in their index (40 days).
Is this about normal?
The rate of changing is slowing down. I would think it would speed up. Silly me.

I had read that it takes from weeks to months.
Am I in good shape? (not to worry?)

Thank you.
.

[robzilla]

Nginx -- not just a reverse proxy, I should emphasize, but itself a full-fledged web server -- has a reputation of being better (i.e. more performant) than Apache when it comes to handling static file requests (a.k.a. "files that actually exist"), so it is (or at least was) often installed for that task alone. Whether this all still holds true, I don't really know. If I recall correctly, nginx was originally written to solve the C10k problem that was crippling Apache at the time. Things have changed quite a bit since then.

Straying off-topic a little bit, but it may be relevant to understanding the nginx-htaccess combination.

In an Apache-plus-nginx combo, who handles requests for nonexistent files, including vanilla 404s? Do they get dumped on Apache, which would explain the need for an ErrorDocument directive? And, contrariwise, if the requested file does exist, does the server still have to look for htaccess?

If by vanilla 404s you mean requests for files that don't actually exist on the hard drive, then usually those will be forwarded to Apache, and Apache, seeing no difference between a request from a client or a client through a reverse proxy, will have to determine if the request is valid and (again through nginx) return the appropriate status code. Only then may a htaccess file come into play, never when nginx handles a request without consulting Apache.

Can you deny requests both on the nginx side and on the Apache side?

Sure, just not the same request :-) (Because a request denied by nginx will never get Apache involved.)

[lucy24]

So then, getting back to the approximate vicinity of the original question: How do protocol-or-host redirects work? Does the static-file business mean that this type of redirect has to come first, before nginx has time to discover that the file physically exists, lest they happily serve up http://example.com/pagename.html instead of the desired https://www.example.com/pagename.html ?

[robzilla]

That's what I would recommend, because it'd more efficient than passing a request that you know will be redirected (like HTTP > HTTPS) through Apache. Your client-facing server will have to take care of the protocol and certificate negotiations anyway. Saves you a file check if you let nginx handle the redirect without first checking if the file exists. On the other hand, checking for the file first can save you a redirect if it doesn't exist, but hopefully you get more request for resources that do exist (whether as files or valid rewritten URIs).