Skip to content

Conversation

@laipz8200
Copy link

@laipz8200 laipz8200 commented Nov 8, 2024

Summary

related #3396.

Currently, a multipart request can only be sent when the files parameter is non-empty. This restriction limits cases where users might want to send data using multipart mode without attaching any files, which is possible in tools like Postman.

Change: Instead of requiring files to be non-empty, we could determine the need for a multipart request based on whether files is None rather than its emptiness. This would allow users to send multipart requests without attaching files if needed.

I think there is no significant documentation update required, so I have not made any changes. However, please let me know if any updates are needed.

Checklist

  • I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.

@laipz8200 laipz8200 marked this pull request as ready for review November 8, 2024 07:02
@lovelydinosaur
Copy link
Contributor

Thanks. I've updated the tests to avoid private imports.

Do we think this is an improved behaviour? It does seem nice that an explicit files={} will enforce multipart. (On the other hand, if data and files are determined dynamically as in the cli we need to explicitly switch to None)

@laipz8200
Copy link
Author

Thanks for the update!

My original plan was to make it easier to use multipart without having to carry files, which wasn’t as straightforward before.

I don’t use the cli much, so if this causes any issues, just let me know.

content=content,
data=dict(data),
files=files, # type: ignore
files=files or None, # type: ignore
Copy link

Choose a reason for hiding this comment

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

I don't think this change is correct. It seems to go against the spirit of your main change in the httpx/_content.py file.
It seems to prevent the fix from working when using the cli.
Although I am not familiar with this usage and I didn't look too much into it, so I don't know if it's even possible to do this through the cli.

Copy link
Author

Choose a reason for hiding this comment

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

Thank you for the review, I'll take a look at the CLI.

@ujayant
Copy link

ujayant commented Jun 1, 2025

@laipz8200 @tomchristie When do you plan to merge this feature? I am running into a similar issue

@ujayant
Copy link

ujayant commented Jun 1, 2025

@tomchristie @laipz8200 Is there a workaround for this in the older versions?

@laipz8200
Copy link
Author

Is there a workaround for this in the older versions?

@ujayant Here is a workaround: #3396 (comment). I apologize for not being able to dedicate time recently to address this issue.

@ujayant
Copy link

ujayant commented Jun 11, 2025

Is there a workaround for this in the older versions?

@ujayant Here is a workaround: #3396 (comment). I apologize for not being able to dedicate time recently to address this issue.

I see this error when I try to use your example - chunk = self.file.read(self.CHUNK_SIZE) AttributeError: 'dict' object has no attribute 'read'. You will have to pass an empty file

@laipz8200
Copy link
Author

Hi @tomchristie,

Sorry for the late reply — I think this PR is ready to be merged.

Regarding the point @sylann raised, I see it as more of a decision question: do we want to offer the same functionality for the CLI as well? If yes, should it be done in this PR?

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