I tried to check this on firefox and IE, I could see the result page having webcontent "letsgo" . I hope this is the expected behavior.

Well yes you should see the "letsgo" page if navigation occurred (without a redirection.)

Alright. Am a newbie to Chromium and I'd like to check debug this issue :).

mmenke, rdsmith, rsleevi: Can one of you take a look?

Adding in Asanka as well, since I suspect he's familiar with C-D from the downloads work.

I'm going to go ahead and WontFix this - the report both misunderstandings how Content-Dispositions work, and the spec.

First off, per RFC 2183, the value before the first semi-colon in the content-disposition line is disposition-type, everything after that is a disposition-parm.  (Note that this is indicated by the use of semi-colon.  HTTP headers with lists of the same type of objects generally use a comma separator.  Ones where the first value is the main value, and the others are parameters generally use semi-colons).

Secondly, per the RFC, unrecognized content-disposition types should be treated as attachment, not inline (See section 2.8 of the RFC), and the empty string is not a recognized content-disposition.

Friendly reminder: reading bug description before replying helps.

I am reporting bogus handling of invalid Content-Disposition headers, namely those starting with one or multiple semicolons. The disposition type is empty in this case which should result in it being treated like inline - it's not an unknown disposition type but rather a missing one. You can look up that logic in HttpContentDisposition::ConsumeDispositionType() in the Chromium code base, and that's how such responses are being treated by Firefox.

However, it seems that there is a second code path within Chromium that I wasn't able to find yet, one that ignores leading semicolons. This second code path causes the strange behavior described in this report. And I am pretty sure that ignoring leading semicolons isn't in line with the RFC.

For reference, we discovered that bug when we tried to "predict" in Adblock Plus whether a particular HTTP response will result in navigation.

Re-opening this, per above comment (Sorry, put this on my todo list, but never got back to thinking about it).

I tried to ignore the leading semicolons and it works fine and we get the same behavior as we see in firefox or IE

Hey, Charles, can I take advantage of your blink expertise? After a bit of source code digging, I spun up a local instance of Chrome and tried to track what happened in ResourceLoader, and it looks like it is successfully completing a GET to "http://chrome-navigation-tester.kzar.co.uk/letsgo/0.338618?statuscode=200&content-type=&location=&content-disposition=%3Bfoo" and handing that over to the AsyncResourceHandler.  Which I think means the problem is further up the loader stack.  Do you know if/where in blink the Content-Disposition header is evaluated?

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/network/HTTPParsers.cpp?rcl=aaf85a1175da26db6baac2735e5d64271c5c8f17&l=270

HTTPParsers maybe is what you're looking for?

Exactly, this looks like the other Content-Disposition parser I was looking for. The logic is similar to HttpContentDisposition but not identical. From what I understand, the problematic line is this one:

  contentDisposition.split(';', parameters);

This implicitly sets allowEmptyEntries parameter to false, so the split will ignore empty strings. Changing it to contentDisposition.split(';', true, parameters) should fix the issue reported here. From the look of it, otherwise the result should be identical to HttpContentDisposition.

Thanks for taking a look trev. To Blink>Loader for assignment, and cc tyoshino, is this in your wheelhouse?

Should we use the same code in net/ and blink/ to parse the header, now that we can?

Removing network label, as it seems this is a blink issue.

> #8
> The disposition type is empty in this case which should result in it being treated like inline

Sorry, can you tell me where it is specified? I skimmed RFC 2183, but failed to find the description.

That's the logic I saw in both Chrome and Firefox code, but I didn't see this case mentioned explicitly in RFC. I guess the idea is that an empty disposition type is the same as no disposition type - meaning that the default behavior applies.

Thanks, hopefully https://codereview.chromium.org/2844353003/ will fix the issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a397826c00c0873475842d7f9d9d03038015dcdf

commit a397826c00c0873475842d7f9d9d03038015dcdf
Author: yhirano <yhirano@chromium.org>
Date: Fri Apr 28 13:30:46 2017

Use net::HttpContentTypeDisposition in blink

This CL replaces blink::GetContentDispositionType implementation by
net::HttpContentTypeDisposition. There are some behavior differences between
these two implementations, but because the former is used only to see if
the disposition type is attachement, there is only one difference that matters.
The former returns kAttachement for empty content disposition type (e.g.,
";foo"), but the latter returns kInline. It looks the former is intended to
return kNone, but it returns kAttachment due to misuse of confusing
WTFString::Split interface.

Hence this CL adds IsContentDispositionAttachment and makes it return false
when a value with an empty content disposition type is given.

BUG= 696967 

Review-Url: https://codereview.chromium.org/2844353003
Cr-Commit-Position: refs/heads/master@{#467977}

[add] https://crrev.com/a397826c00c0873475842d7f9d9d03038015dcdf/third_party/WebKit/LayoutTests/http/tests/loading/empty-content-disposition-type.html
[add] https://crrev.com/a397826c00c0873475842d7f9d9d03038015dcdf/third_party/WebKit/LayoutTests/http/tests/loading/resources/empty-content-disposition-type.php
[modify] https://crrev.com/a397826c00c0873475842d7f9d9d03038015dcdf/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
[modify] https://crrev.com/a397826c00c0873475842d7f9d9d03038015dcdf/third_party/WebKit/Source/platform/network/HTTPParsers.cpp
[modify] https://crrev.com/a397826c00c0873475842d7f9d9d03038015dcdf/third_party/WebKit/Source/platform/network/HTTPParsers.h