SyncTriggers failing if http used on an "https-only" app

[brettsam]

If a customer has these two settings...

• SCM_SKIP_SSL_VALIDATION=1
• HTTPS Only = On (viewable in portal)

...the functions host will attempt to make an http request to SyncTriggers. This will fail with a 404.

It ends up being a 404 because the request follows the following path:

• POST (with payload) issued to http://{sitename}/operations/settriggers
• Antares FrontEnd returns a 301 MovedPermanently -- which the HttpClient follows this -- which becomes https -- and turns from a POST into a GET while dropping the payload. I never knew this happened, but context:
  • RFC explaining that 301 can become GET
  • .NET RedirectHandler code that does a "force GET" when following redirects on a 301 with a POST
• this GET is not handled by the FrontEnd (it only intercepts POSTs) and makes its way back to the site itself, which returns a 404... to itself.

There's several investigations we can make here:

1. Does this request need to be http? https does seem to work as the GET works. Don't have much context, but here is the code.
2. If it does have to be http in this case, we can change AllowAutomaticRedirect in the HttpClient, handle the 301 directly, and present a nice error to the customer. Or use DiagnosticEvents, etc -- but provide guidance on how to get SyncTriggers working again.

[mathewc]

Looks like this was added 6 years ago in this commit by @balag0 - he may help provide more context on this.

Looking in the older Kudu code here that also does an /operations/settriggers, it handles this in a different way, via HttpClient configuration. I wonder if we shouldn't just do the same thing in the host.