Skip to content

Conversation

@markekraus
Copy link
Contributor

@markekraus markekraus commented Sep 8, 2017

Summary

Partially implements #2112

  • Adds System.Net.Http.MultipartFormDataContent as a possible type for -Body
  • Adds /Multipart/ test to WebListener

This allows for the user to create their own Http.MultipartFormDataContent object and submit it. Since multipart/form-data submissions are highly flexible, adding direct support for it to the CmdLets may over-complicate the command parameters and a limited implementation would not address the broad scope of use cases. This at least allows the user to submit multipart forms using the Web Cmdlets and not have to manage their own HttpClient. Once this is introduced, limited multipart implementations can be expanded to use the code in this PR.

Documentation Needed

Note that documentation will probably need to make clear that -ContentType will be ignored when a MultipartFormDataContent object is supplied to -Body. Similarly, content headers specified by -Headers and -WebSession will be ignored too.

ContentType must be set by the MultipartFormDataContent object as it controls the boundary in the Content-Type header used to distinguish between the various fields supplied. It doesn't make sense to use any other Content-Type header when doing multipart/form-data anyway. If this isn't done here, the Foreach on line 421 throws. when Content is set with a MultipartFormDataContent it overwrites all the content headers, so trying to add content headers again causes an exception about ContentType already exists.

@msftclas
Copy link

msftclas commented Sep 8, 2017

@markekraus,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

CI Rerun count: I
else if (content is MultipartFormDataContent)
{
WebSession.ContentHeaders.Clear();
MultipartFormDataContent multipartFormDataContent = content as MultipartFormDataContent;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should exclude double casting. Here it is better use C# 7.0 pattern:

else if (content is MultipartFormDataContent multipartFormDataContent ) 

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome. I will do that.

if (request == null)
throw new ArgumentNullException("request");
if (multipartContent == null)
throw new ArgumentNullException("multipartContent");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use curly braces:

if ( ... )
{
    ...
}

or single line operator.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do this, but it will not match the surrounding code.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we should use approved patterns for new code.
You can wait a view of other maintainers.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agreed with @iSazonov. The new code is somewhat isolated as it's in its own method, so I think it's fine to use the more preferred style.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@daxian-dbw Awesome! format is already corrected in the most recent commit for this PR.

}
public ActionResult Index()
{

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove extra line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

}

Context "Multipart/form-data Tests" {
It "Verifies Invoke-WebRequest Supports Multipart String Values" {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use the same Context header 😕
I believe we should add cmdlet name Context "Invoke-WebRequest Multipart/form-data Tests"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, because they are under different describe blocks. We did the same thing with HTTPS

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's somewhat confusing, but we can leave it for Context.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For clarity, would you like me to change it or leave it as is?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave it as is.

}

Context "Multipart/form-data Tests" {
It "Verifies Invoke-RestMethod Supports Multipart String Values" {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Context "Invoke-RestMethod Multipart/form-data Tests"

@daxian-dbw daxian-dbw self-assigned this Sep 8, 2017
Copy link
Member

@daxian-dbw daxian-dbw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@markekraus Thank you for the good work! Could you please take a look at the 2 comments I left?

}
else if (content is MultipartFormDataContent multipartFormDataContent)
{
WebSession.ContentHeaders.Clear();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WebSession.ContentHeader is set at line 325 when ContentType is specified. Is it OK to ignore that as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, ContentType must be set by the MultipartFormDataContent object as it controls the boundary in the Content-Type header used to distinguish between the various fields supplied. Documentation will probably need to make clear that -ContentType will be ignored when a MultipartFormDataContent object is supplied. It doesn't make sense to use any other Content-Type header when doing multipart/form-data anyway. If this isn't done here, the Foreach on line 421 throws. when Content is set with a MultipartFormDataContent it overwrites all the content headers, so trying to add content headers again causes an exception about ContentType already existing.

Copy link
Member

@daxian-dbw daxian-dbw Sep 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification. I updated the PR description to capture your words.

Then there is a potential problem at line 239
Nevermind, GetRequest happens before FillRequestStream, so we are good. Updated the PR description to mention -Header and -WebSession will be ignored as well.

$fileContent.Headers.ContentType = [System.Net.Http.Headers.MediaTypeHeaderValue]::Parse("text/plain")
$multipartContent.Add($fileContent)
}
# unary comma required
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can you please also mention why it's required -- $multipartContent will be unwrapped/enumerated otherwise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@daxian-dbw daxian-dbw added the Documentation Needed in this repo Documentation is needed in this repo label Sep 11, 2017
Copy link
Member

@daxian-dbw daxian-dbw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@daxian-dbw daxian-dbw merged commit fd3a003 into PowerShell:master Sep 12, 2017
@daxian-dbw
Copy link
Member

@markekraus Thanks again for the good work!

@markekraus
Copy link
Contributor Author

@daxian-dbw For documentation, when is that handled? Should I submit a PR/Issue to PowerShell-Docs now or does it need to wait for the next beta release?

@daxian-dbw
Copy link
Member

Yes, you are welcome to submit a PR to PowerShell-Docs now :)
Here is the guideline for maintainers about PRs that require doc changes (see CONTRIBUTING.md):

If your change warrants an update to user-facing documentation, a Maintainer will add the Documentation Needed label to your PR and add an issue to the PowerShell-Docs repository, so that we make sure to update the official documentation to reflect your contribution. As an example, this requirement includes any changes to cmdlets (including cmdlet parameters) and features which have associated about_* topics. While not required, we appreciate any contributors who add this label and create the issue themselves. Even better, all contributors are free to contribute the documentation themselves. (See Contributing to documentation related to PowerShell for more info.)

Please see https://github.com/PowerShell/PowerShell/blob/master/.github/CONTRIBUTING.md#contributing-to-documentation for more details

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants