23 votesAnonymous commented
I don’t know if responses from the app service are routed directly back to the user agent or if they travel back through the application gateway (AG).
If response traffic is routed through the AG on its way back to the user agent, the AG would have all the information required to rewrite the domain in the set ARRAffinity cookie header. The logic flow would look something like this:
1. A user agent request comes in on the AG frontend listener bound to “contoso.com”.
2. The AG routes the request to the backend app service which has the default binding of “contoso.azurewebsites.com”.
3. The app service processes the request and generates a response.
4. The response arrives at the AG on its way back to the user agent. The response contains a “Set ARRAffinity cookie” header with “Domain=contoso.azurewebsites.com” attribute set.
5. Since the AG knows the frontend listener hostname and the backend app service hostname it could modify the “set ARRAffinity cookie” response header, rewriting the domain attribute from the backend hostname “contoso.azurewebsites.com” to the front end listener hostname “contoso.com”.
6. The response would then be sent on to the user agent who will store the cookie (since the domain matches the request hostname).
7. Now that the user agent has a valid ARRAffinity cookie, it gets sent on subsequent requests as intended.
I like this approach because it is internal to the app gateway which prevents a rouge user agent that might purposely bypass the AG but include an X-Original-Host request header in an effort to spoof an AG. In essence, the AG will be solving the very problem it creates without involving custom code in the app service or modification to any other Azure services. I don’t see a scenario where this would not be the desired functionality but if there is one, the AG configuration could include a “Use front end hostname for ARRAffinity cookie” checkbox option.Anonymous shared this idea ·
Thanks for the feedback! We are interested in collecting feedback on this request – please vote for it if this is something you like to see.
We’re also interested in learning more what people want to use the SFTP/FTPS for and which protocol they prefer. Please feel free to leave us a comment letting us know more detail!
Program Manager, Azure FilesAnonymous commented
We have many customers with automated processes setup that involve involve pushing or pulling files from us via SFTP. The hassle of migrating those customers to a new endpoint on Azure will be tough enough, but to change the protocol may make the migration impossible, and we can't tell our customers that won't/can't support REST to just go away.