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

Jump to bottom

mime/multipart: Use Content-Length for individual mime parts when available #8665

Closed
gopherbot opened this issue Sep 5, 2014 · 2 comments
Closed

mime/multipart: Use Content-Length for individual mime parts when available #8665

gopherbot opened this issue Sep 5, 2014 · 2 comments
Labels
FrozenDueToAge

Comments

@gopherbot
Copy link

by renan.saddam:

When using the mime/multipart Reader would be nice if when it sees Content-Length header
on the individual part it would be used rather than searching for the boundary.

I am not sure what is the overhead of doing a boundary comparison on the content but I
think using Content-Length will be much faster, specially when dealing with large
multipart objects.
@ianlancetaylor
Copy link
Contributor

Comment 1:

Labels changed: added repo-main, release-none.

@bradfitz
Copy link
Contributor

bradfitz commented Sep 5, 2014

Comment 2:

I think this would just lead to new bugs because the Content-Type won't exactly match
the number of bytes after encoding, especially after quoted-printable.
Nobody's ever worked on profiling or optimizing this code. I'd prefer to see that done
before anybody attempts something like this.
Closing this bug, but feel free to do your own experiments and post your findings.

Status changed to WontFix.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@bradfitz @ianlancetaylor @gopherbot