locked
Simple Invoke-WebRequest produces protocol violation when attempting to XML login to a web based peripheral. RRS feed

  • Question

  • I have tried a number of variations on a theme to work around this problem. But every thing that I have tried is for not. I am simply not as familiar with the PS as I am with Bash and Wget.  But I need this to work in powershell. If you can help that would be great. I am trying to get the XML out back into my Shell.

    $G=Invoke-WebRequest-Urilogin.xml-OutFilec:\test.out

    Produces this error.

    Invoke-WebRequest : The server committed a protocol violation.

    Section=ResponseStatusLine

    At line:1 char:1

    + Invoke-WebRequest -Uri login.xml -OutFile c:\test.out

    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:Htt

       pWebRequest) [Invoke-WebRequest], WebException

        + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe

       ll.Commands.InvokeWebRequestCommand

    After a few web searches, I found a couple of suggestions – one of which said the problem could be fixed by changing the HttpWebRequest ProtocolVersion to 1.0 with the command: But I don't know how to get past this.

       1:  HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create(strURI);
       2:  req.ProtocolVersion = HttpVersion.Version10;

     



    • Edited by D Peterson Monday, November 24, 2014 8:05 PM
    Monday, November 24, 2014 8:03 PM

Answers

  • Hi Peterson,

    Have you checked the method to set "useUnsafeHeaderParsing" to "true" in application configuration file?

    Refer to:

    Protocol violation - can I change how sensible the test shall be to protocol errors?

    I also found an article which describe we can add "useUnsafeHeaderParsing" in the file powershell.exe.config to ignore the protocol violations.

    Or you can also try to run this script before running the cmdlet "Invoke-WebRequest":

    $netAssembly = [Reflection.Assembly]::GetAssembly([System.Net.Configuration.SettingsSection])
    
    if($netAssembly)
    {
        $bindingFlags = [Reflection.BindingFlags] "Static,GetProperty,NonPublic"
        $settingsType = $netAssembly.GetType("System.Net.Configuration.SettingsSectionInternal")
    
        $instance = $settingsType.InvokeMember("Section", $bindingFlags, $null, $null, @())
    
        if($instance)
        {
            $bindingFlags = "NonPublic","Instance"
            $useUnsafeHeaderParsingField = $settingsType.GetField("useUnsafeHeaderParsing", $bindingFlags)
    
            if($useUnsafeHeaderParsingField)
            {
              $useUnsafeHeaderParsingField.SetValue($instance, $true)
            }
        }
    }

    For more detailed information, please go through this article:

    Ignoring SSL trust in PowerShell System.Net.WebClient

    If there is anything else regarding this issue, please feel free to post back.

    Best Regards,

    Anna Wang

    • Edited by AnnaWY Tuesday, November 25, 2014 10:33 AM
    • Proposed as answer by AnnaWY Tuesday, December 2, 2014 12:30 PM
    • Marked as answer by AnnaWY Thursday, December 4, 2014 3:18 AM
    Tuesday, November 25, 2014 10:30 AM
  • Hi Anna.

    I added

    <system.net>
    <settings>
    <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
    </system.net> 
    to my powershell.exe.config file and that worked. Thank you.

    • Proposed as answer by AnnaWY Tuesday, December 2, 2014 12:30 PM
    • Marked as answer by AnnaWY Thursday, December 4, 2014 3:18 AM
    Tuesday, November 25, 2014 6:30 PM

All replies

  • Maybe contact webmaster and ask them to fix the server. 

    Maybe your XML file is not a URI or it is not correct XML?


    ¯\_(ツ)_/¯

    Monday, November 24, 2014 9:29 PM
  • Using a file URI just opens the file as an object.  THe RawContent property will have the contents of the file.  No other action is taken.  YOUr file must be in correct format forXML.


    ¯\_(ツ)_/¯

    Monday, November 24, 2014 9:34 PM
  • Hi Peterson,

    Have you checked the method to set "useUnsafeHeaderParsing" to "true" in application configuration file?

    Refer to:

    Protocol violation - can I change how sensible the test shall be to protocol errors?

    I also found an article which describe we can add "useUnsafeHeaderParsing" in the file powershell.exe.config to ignore the protocol violations.

    Or you can also try to run this script before running the cmdlet "Invoke-WebRequest":

    $netAssembly = [Reflection.Assembly]::GetAssembly([System.Net.Configuration.SettingsSection])
    
    if($netAssembly)
    {
        $bindingFlags = [Reflection.BindingFlags] "Static,GetProperty,NonPublic"
        $settingsType = $netAssembly.GetType("System.Net.Configuration.SettingsSectionInternal")
    
        $instance = $settingsType.InvokeMember("Section", $bindingFlags, $null, $null, @())
    
        if($instance)
        {
            $bindingFlags = "NonPublic","Instance"
            $useUnsafeHeaderParsingField = $settingsType.GetField("useUnsafeHeaderParsing", $bindingFlags)
    
            if($useUnsafeHeaderParsingField)
            {
              $useUnsafeHeaderParsingField.SetValue($instance, $true)
            }
        }
    }

    For more detailed information, please go through this article:

    Ignoring SSL trust in PowerShell System.Net.WebClient

    If there is anything else regarding this issue, please feel free to post back.

    Best Regards,

    Anna Wang

    • Edited by AnnaWY Tuesday, November 25, 2014 10:33 AM
    • Proposed as answer by AnnaWY Tuesday, December 2, 2014 12:30 PM
    • Marked as answer by AnnaWY Thursday, December 4, 2014 3:18 AM
    Tuesday, November 25, 2014 10:30 AM
  • Hi Anna.

    I added

    <system.net>
    <settings>
    <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
    </system.net> 
    to my powershell.exe.config file and that worked. Thank you.

    • Proposed as answer by AnnaWY Tuesday, December 2, 2014 12:30 PM
    • Marked as answer by AnnaWY Thursday, December 4, 2014 3:18 AM
    Tuesday, November 25, 2014 6:30 PM
  • Hi Peterson,

    Glad to hear that =)

    Wednesday, November 26, 2014 2:02 AM