Invoke-RESTMethod truncating request URI string

This topic contains 0 replies, has 1 voice, and was last updated by Profile photo of Forums Archives Forums Archives 5 years, 5 months ago.

  • Author
    Posts
  • #5313

    by davidski at 2012-11-29 15:08:43

    I have a request URI in the format of: https://server/path/path/Application+Mappings/A.R.E.S./ when I pass this via irm -verbose I see https://server/path/path/Application+Mappings/A.R.E.S/ is being sent to the REST server. Note the removal of the last period. Proxying the traffic via Fiddler I see that the period is actually getting truncated on the request, which a manual web browser does not do. All my other URLs work fine. Attempts to encode this with %2E as a period representation also get truncated.

    Is there some syntax checking that I'm violating somehow here or is this an actual bug in Invoke-RESTMethod?

    David

    by DonJ at 2012-11-29 15:15:23

    It sounds like a bug in the cmdlet, particularly if it's truncating the URL-encoded character. I'd log it in Connect, if it isn't there already.

    by davidski at 2012-11-30 07:59:52

    Darn. I was hoping I was doing something wrong. :/ Connect issue "Invoke-RESTMethod truncates final period of URIs" submitted.

    With PoSH bundled with the OS, how would a bugfix for something like this be distributed? Would a .NET update catch these sorts of things or are we looking at a Win-MF update or even a full OS release to pick up PoSH language fixes?

    by DonJ at 2012-11-30 08:05:59

    It depends on where the bug actually lives – if it's a cmdlet bug, the PowerShell team fixes it, if it's a Framework bug, the Framework team has to fix it. But regardless, it'll be either a hotfix or service pack depending on how it gets prioritized. I doubt it'd be a full Win-MF release. It's possible it could get prioritized down into the next full OS release, but it's impossible to say.

    There are already PowerShell bugs being fixed by hotfix, so that's not out of the question. Again – depends a bit on whose code actually contains the bug.

You must be logged in to reply to this topic.