Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MulitpartBody does not write out simple string values #300

Closed
waynebrantley opened this issue Jul 18, 2024 · 5 comments
Closed

MulitpartBody does not write out simple string values #300

waynebrantley opened this issue Jul 18, 2024 · 5 comments
Labels
Needs: Attention 👋 type:question An issue that's a question

Comments

@waynebrantley
Copy link

Given code like this:

        var multipartBody = new MultipartBody();
        multipartBody.AddOrReplacePart("Name", "application/x-www-form-urlencoded", "SomeName");
        multipartBody.AddOrReplacePart("Address", "application/x-www-form-urlencoded", "SomeAddress");

The parts inside MulitpartBody are correctly setup.
Serialize is called and this line of code executes: https://github.com/microsoft/kiota-dotnet/blob/main/src/abstractions/MultipartBody.cs#L148

As you can see it calls partWriter.WriteStringValue(string.Empty, currentString); and the first parameter of WriteStringValue is always empty. When writing out a form, that calls this code: https://github.com/microsoft/kiota-dotnet/blob/main/src/serialization/form/FormSerializationWriter.cs#L220

If you look at this line if(string.IsNullOrEmpty(key) || string.IsNullOrEmpty(value)) return;, it is always true because the key is always empty!

This results in none of the string values actually being written out.

The current tests you have around everything always mock out serialization library - so it does not reveal that it always calls with an empty string. Additionally, the tests for the FormSerializationWriter always pass in a key, so that does not reveal this issue either.

It appears that the Serialize code always passes empty key for all types of content so those are likely wrong too. In addition, this line effectively is a no-op also: https://github.com/microsoft/kiota-dotnet/blob/main/src/abstractions/MultipartBody.cs#L121

@andrueastman
Copy link
Member

Thanks for raising this @waynebrantley

The issue here is essentially a duplicate of #247 (comment) that needs some investigation.

The thing is that if we pass would you expect the payload to contain both key/values? Or just the values?

multipartBody.AddOrReplacePart("Name", "application/x-www-form-urlencoded", "SomeName");
multipartBody.AddOrReplacePart("Address", "application/x-www-form-urlencoded", "SomeAddress");

If only values, does it make sense to change to this?

multipartBody.AddOrReplacePart("Name", "text/plain", "SomeName");
multipartBody.AddOrReplacePart("Address", "text/plain", "SomeAddress");

@andrueastman andrueastman added the status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close label Jul 19, 2024
@waynebrantley
Copy link
Author

Essential duplicate - sorry about that, I saw that ticket and thought it was all about the extra CRLF.

Good question. If the type is x-www-form-urlencoded, then it would be expected to be key=value&key=value, etc.
If not then it would just be the value - as the form-data has the key name in it. Sort of weird to pass x-www-form-urlencoded in form-data because the form-data has the name. Not sure what asp.net would do with that? Look for a variable with that name and then populate the properties from the x-www-form-urlencoded?

High level, we we expecting just the data to come out as it was form-data and was not sure how the encoded would work.

We are really struggling getting an open api definition that kiota can call successfully, if that mapPost contains IFile and other data along with the file. Its either an open api generation issue (swashbuckle/nswag) or a kiota issue or both, it is a bit of a mess! :-)

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs: Attention 👋 and removed status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close labels Jul 19, 2024
@baywet
Copy link
Member

baywet commented Jul 19, 2024

Thanks for the additional context. Out of curiosity, what are you using to generate the description?

@baywet baywet added Needs: Author Feedback status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close type:question An issue that's a question and removed Needs: Attention 👋 labels Jul 19, 2024
@waynebrantley
Copy link
Author

currently Swashbuckle. Cannot wait for the built-in openapi support.
We did try the text/plain and that seemed to work much better.

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs: Attention 👋 and removed status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close labels Jul 19, 2024
@baywet
Copy link
Member

baywet commented Jul 20, 2024

Thanks for confirming. Closing.

@baywet baywet closed this as completed Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs: Attention 👋 type:question An issue that's a question
Projects
Archived in project
Development

No branches or pull requests

3 participants