New issue
Advanced search Search tips

Issue 678144 link

Starred by 1 user

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Headers are mismatched in multipart images

Project Member Reported by hirosh...@chromium.org, Jan 4 2017

Issue description

In a multipart image like:
Content-Type: multipart/x-mixed-replace; boundary=boundary

--boundary
Content-Type: image/svg+xml; Header1

<Body1.svg>
--boundary
Content-Type: image/jpeg; Header2

<Body2.jpeg>
--boundary
Content-Type: image/svg+xml; Header3

<Body3.svg>
--boundary
<End of response>

Header1 should be used with Body1,
Header2 should be used with Body2,
Header3 should be used with Body3,
and so on.

However in chromium,
Header2 is used when the image for Body1 is created,
Header3 is used when the image for Body2 is created,
Header3 is used when the image for Body3 is created.

This is because, in ImageResource::onePartInMultipartReceived, setResponse(response) (that sets the response for the next part) is called before updateImageAndClearBuffer() (that creates the image for the previous part).

I'm not sure whether this causes real problems other than failing to open multipart images with svg/jpeg mixed though.
(Firefox can open such an image while Chromium shows an broken image, but I think we don't have to support such cases because use cases are rare (none?) and Chromium has been unable to open such files since long ago)

 
Status: Started (was: Untriaged)
CL: https://codereview.chromium.org/2610083002
Even after the CL in #1 the image content and the response header are still inconsistent, because while the image of Body1 is shown, the response header is Header2 if someone checks it.
Because the differences of the headers for parts are small (can only differ in "content-type", "content-length", "content-disposition", "content-range", "range", "set-cookie" headers listed in platform/network/HTTPParsers.cpp) and are not security-related, perhaps we can ignore this inconsistencies?

(My context for this issue is preparation for refactoring of the timings of updating image contents and response headers; while summarizing the current behavior, I found this)
You started fixing this bug over two years ago. Are you still working on it? You can update the status to "archived", "wontfix", or "closed". You can remove yourself as owner and change status to "untriaged", but if this is still a real bug, please do not sit on it.

Sign in to add a comment