Bug 168299 – [SOUP] Ensure a response MIME type when Content-Type is missing and sniffing not allowed

• Component: WebKit2
• Status: RESOLVED FIXED

[Carlos Garcia Campos]

Sniffing is not allowed but we can try to guess the MIME using the response path, or at least fallback to default MIME type instead of leaving an empty string. This will fix a couple of tests that expect application/octet-stream in this particular case.

[Carlos Garcia Campos]

Created attachment 301481 [details]
Patch

[Sergio Villar Senin]

Comment on attachment 301481 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=301481&action=review

> Source/WebKit2/NetworkProcess/soup/NetworkDataTaskSoup.cpp:334
> +        }

What about just adding

if (m_response.mimeType().isEmpty() && m_soupMessage->status_code != SOUP_STATUS_NOT_MODIFIED)
    m_response.setMimeType(MIMETypeRegistry::getMIMETypeForPath(m_response.url().path()));

to the previous code? I prefer that option because it  clearly shows that the call to updateFromSoupMessage is unconditional.

[Carlos Garcia Campos]

Comment on attachment 301481 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=301481&action=review

>> Source/WebKit2/NetworkProcess/soup/NetworkDataTaskSoup.cpp:334
>> +        }
> 
> What about just adding
> 
> if (m_response.mimeType().isEmpty() && m_soupMessage->status_code != SOUP_STATUS_NOT_MODIFIED)
>     m_response.setMimeType(MIMETypeRegistry::getMIMETypeForPath(m_response.url().path()));
> 
> to the previous code? I prefer that option because it  clearly shows that the call to updateFromSoupMessage is unconditional.

Yes, I thought about that, and I didn't do it to avoid checking 304 twice, but it's not a big deal anyway. I'll update it before landing, thanks for the review.

[Carlos Garcia Campos]

Committed r212286: <http://trac.webkit.org/changeset/212286>