You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
...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:
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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.
If a customer has these two settings...
SCM_SKIP_SSL_VALIDATION
=1
...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 tohttp://{sitename}/operations/settriggers
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:There's several investigations we can make here:
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.The text was updated successfully, but these errors were encountered: