Jump to content
Welcome to our new Citrix community!

enable HTTP verb OPTIONS


Dany Demers

Recommended Posts

Hi, runing Netscaler ADC 12.0-60.10 and we're experiencing problem with outlook mobile app for android and exchange 2010 since version 4.0.65 or higher, the microsoft engineer that we talked to says that the problem might come from the "device" between the exchange server and the mobile app. He said that we need to enable the "HTTP verb OPTIONS" referenced by this article: https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-ashttp/f86491ea-4908-43df-918f-f016b65f5e90

how do I know if this is supported on the Netscaler and how can I prove that it's working ?

Link to comment
Share on other sites

By default the Netscaler shouldn't be blocking HTTP OPTIONS requests, but you may have other policies (application firewall, responder, etc) that disallow it.

 

You should be able to capture a trace to see what happens when the mobile app sends an OPTIONS request. Run the trace and filter on the mobile app/client IP address to see the request to the Netscaler and the response that the Netscaler returns.

Link to comment
Share on other sites

Thanks, I did some test with SOAPUI and if I connect straight to a LB vip the OPTIONS verb works good but as soon as I connect to a CS vip that front the same LB vserver then I can't get the verb OPTIONS to work. I even try to add another CS policy with just "true" to make sure it will match and forward the request to the backend but it still doesn't work, compared to if I point straight to the LB then I can get a successfull response with the OPTIONS. Any help would be appreciated.

Link to comment
Share on other sites

I just tested in my lap and didn't have any issues with options to an LBVS or a CSVS with an LBVS behind it.

 

Config:

add lb vserver options-test-lb HTTP 192.168.202.155 80 -persistenceType NONE -cltTimeout 180 -appflowLog DISABLED
add cs vserver options-test-csvs HTTP 192.168.202.156 80 -cltTimeout 180 -appflowLog DISABLED -persistenceType NONE
bind cs vserver options-test-csvs -lbvserver options-test-lb
bind lb vserver options-test-lb my-backend-server

Testing:

> curl -v -X OPTIONS http://192.168.202.155/
...
OPTIONS / HTTP/1.1
Host: 192.168.202.155
User-Agent: curl/7.61.1
Accept: */*

HTTP/1.1 200 OK
Date: Thu, 09 Jan 2020 19:33:11 GMT
Allow: GET,POST,HEAD,OPTIONS,TRACE
Content-Length: 0
Content-Type: text/html; charset=UTF-8


> curl -v -X OPTIONS http://192.168.202.156/
...
OPTIONS / HTTP/1.1
Host: 192.168.202.156
User-Agent: curl/7.61.1
Accept: */*

HTTP/1.1 200 OK
Date: Thu, 09 Jan 2020 19:33:16 GMT
Allow: GET,POST,HEAD,OPTIONS,TRACE
Content-Length: 0
Content-Type: text/html; charset=UTF-8

Watching the HTTP access logs on the backend server also shows successful OPTIONS requests reached for both requests.

  • Like 1
Link to comment
Share on other sites

Upon further testing it appear that it's not the CS vserver that makes a difference but the fact that the one behind the Cs Vserver has a 401 Auth Vserver on it. When I test withouth the auth vserver I can reach the mail server which prompt for authentication that I provide in SOAPUI and then I receive the answer

"HTTP/1.1 200 OK" 

 

But as soon as I put the 401 auth vserver on the LB then I just seem to do an infinite loop and even putting in bad credential into SOAPUI doesn't change the behavior...

 

Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "Accept-Encoding: gzip,deflate[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "Host: webmail.company.com[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "Connection: Keep-Alive[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "User-Agent: Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "Accept-Encoding: gzip,deflate[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "Host: webmail.company.com[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "Connection: Keep-Alive[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "User-Agent: Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
Thu Jan 09 16:25:29 EST 2020:DEBUG:>> "[\r][\n]"

We really prefer to have the Netscaler authentication in front to prevent invalid attempt to reach our backend server... So any more input would be appreciated. I can't guarantee that it's not SOAPUI that doesn't handle the request badly but but I'm no expert in web diagnostic and that's the tool that I found to test web request in windows.

 

 

Link to comment
Share on other sites

Upon even further testing it appears I didn't even needed SOAPUI to test all that as curl is built in windows 10 so I ended up using your command to test and it works good when I add the following option to your original request:

 

curl -v -X OPTIONS http://192.168.202.155/

curl -v -X OPTIONS https://webmail.company.com/microsoft-Server-ActiveSync -u company\USERNAME

I then get prompted to enter the password for the username and then I can succesfully reach the mail server

 

Thanks for your help in this matter, I can now return to the microsoft engineer that this indeed works good and that is not the problem.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...