locked
Warning #18: Invalid Request Version RRS feed

  • Question

  • Hi All,

    Any reason why I always get Warning #18: Invalid Request Version in my event viewer?  The messages pop up every second for all my trunks.

    Thanks.

    Wednesday, June 30, 2010 1:43 PM

Answers

  • Hi BingDude,

     Do you happen to be using an F5 loadbalancer in front of UAG/IAG?  If so is it using a monitor rule that makes a request for /   I assume that if it's not an F5 it's some other load balancer that does some similar monitoring.  This problem is caused because the way in which F5 and UAG work.  When UAG recieves a requiest for the / path it redirects that request via a HTTP 302 redirect to the first part of the UAG login process, F5 recieves this HTTP 302 redirect and attempts to follow the redirect but in doing so fails to send a valid HTTP Version header with the request which UAG/IAG then report with this error.

    The solution to resolving this problem is quite easy, create an empty file named test.vbs.sig in the ..\von\internalsite\customupdate\ directory and then configure the F5 to make a request for https://portal.contoso.com/internalsite/customupdate/test.vbs.sig  This is the best possible test as the file will return a very small result to the F5 and will not redirect. I would also recomend configuring the F5 monitor look for a specific string in that file  rather than the OK 200 HTTP status code.  This will insure that the node is brought down when the page returned does not contain the correct text from test.vbs.sig.  In order to do this add some unique text in the file that would not be found on any of the UAG/IAG error pages.  For example add the text willywonka to teh test.vbs.sig file and have the F5 Monitor look for that text.

    Lastly the reason to use a file with an extention of .vbs.sig is that it's a file type and path that UAG/IAG will allow without modificaiton to the URL rulesets as well as a type of file can not be executed by anything and doesn't have any specific meaning outside of UAG.

    Regards,
    Dan Herzog
    Microsoft CSS IAG/UAG Support

    • Proposed as answer by djh-msft Thursday, July 1, 2010 6:40 AM
    • Marked as answer by Erez Benari Monday, July 26, 2010 9:26 PM
    Thursday, July 1, 2010 6:40 AM

All replies

  • what is being shown in the web monitor ?
    Wednesday, June 30, 2010 3:11 PM
  •  Warning 6/30/2010 15:20 18 Invalid Request Version Security xxxxx Request failed, invalid HTTP protocol version: HTTP/0.9.
     Warning 6/30/2010 15:20 18 Invalid Request Version Security yyyyy Request failed, invalid HTTP protocol version: HTTP/0.9.
     Warning 6/30/2010 15:20 18 Invalid Request Version Security zzzzzz Request failed, invalid HTTP protocol version: HTTP/0.9.

    This is an excerpt from the web monitor.

     

    Wednesday, June 30, 2010 7:23 PM
  • UAG (and IAG, not sure which one you are using) expects to receive requests that are using HTTP/1.0 or HTTP/1.1.

    I can't say I remember seeing any browser using HTTP/0.9. Do you have some monitoring tool that polls the trunk, which may be sending using this old HTTP version?

    -Ran

    Thursday, July 1, 2010 4:15 AM
  • Hi BingDude,

     Do you happen to be using an F5 loadbalancer in front of UAG/IAG?  If so is it using a monitor rule that makes a request for /   I assume that if it's not an F5 it's some other load balancer that does some similar monitoring.  This problem is caused because the way in which F5 and UAG work.  When UAG recieves a requiest for the / path it redirects that request via a HTTP 302 redirect to the first part of the UAG login process, F5 recieves this HTTP 302 redirect and attempts to follow the redirect but in doing so fails to send a valid HTTP Version header with the request which UAG/IAG then report with this error.

    The solution to resolving this problem is quite easy, create an empty file named test.vbs.sig in the ..\von\internalsite\customupdate\ directory and then configure the F5 to make a request for https://portal.contoso.com/internalsite/customupdate/test.vbs.sig  This is the best possible test as the file will return a very small result to the F5 and will not redirect. I would also recomend configuring the F5 monitor look for a specific string in that file  rather than the OK 200 HTTP status code.  This will insure that the node is brought down when the page returned does not contain the correct text from test.vbs.sig.  In order to do this add some unique text in the file that would not be found on any of the UAG/IAG error pages.  For example add the text willywonka to teh test.vbs.sig file and have the F5 Monitor look for that text.

    Lastly the reason to use a file with an extention of .vbs.sig is that it's a file type and path that UAG/IAG will allow without modificaiton to the URL rulesets as well as a type of file can not be executed by anything and doesn't have any specific meaning outside of UAG.

    Regards,
    Dan Herzog
    Microsoft CSS IAG/UAG Support

    • Proposed as answer by djh-msft Thursday, July 1, 2010 6:40 AM
    • Marked as answer by Erez Benari Monday, July 26, 2010 9:26 PM
    Thursday, July 1, 2010 6:40 AM
  • Hi Dan,

    Thanks for the info.  We do have a F5 in front of the IAG.  I'll give your suggestion a try.

    Thanks,

    Bill

    Tuesday, July 6, 2010 12:58 PM