Commit 7474a735 authored by abarth@webkit.org's avatar abarth@webkit.org

Remove DocumentWriter::deprecatedFrameEncoding()

https://bugs.webkit.org/show_bug.cgi?id=67882

Reviewed by Eric Seidel.

Three years ago, in http://trac.webkit.org/changeset/39026, Alexey
Proskuryakov added ContentDispositionEncodingFallbackArray to work
around a web site compatibility issue with a non-ASCII file name
becoming garbled when received in the Content-Disposition header.

Since that time, there has been copious discussion of this topic among
browser vendors, in the IETF, and in the broader web community.  For
example, here is a Stack Overflow thread about this topic:

http://stackoverflow.com/questions/93551/how-to-encode-the-filename-parameter-of-content-disposition-header-in-http

Eric Lawrence has written a blog post that summarizes IE's perspective
on this issue:

http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx

The current consensus is that browsers should implement RFC 6266,
which is a new RFC that updates the definition of the
Content-Disposition header.  Chrome and Firefox have both implemented
RFC 6266 and have encountered only one issue, which was then fixed by
the web site operator.  IE has also implemented RFC 6266, but I don't
have detailed information about their compatibility experience.

This patch add explicit PLATFORM #ifdefs around the quirky
implementation previously used in Apple's Mac and Windows ports.  This
code is already only used on Apple's ports, so this patch introduces no
functional changes.  It does, however, discourage other ports from
adopting this quirk.  IMHO, Apple should remove this quirk as soon as
compatibility allows and converge behavior with the other major browser
vendors.

See bug for manual test (the bug manifests in Safari download UI).

* loader/DocumentWriter.cpp:
* loader/DocumentWriter.h:
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::addExtraFieldsToRequest):
* platform/network/ResourceRequestBase.cpp:
(WebCore::ResourceRequestBase::adopt):
(WebCore::ResourceRequestBase::copyData):
* platform/network/ResourceRequestBase.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@94902 268f45cc-cd09-0410-ab3c-d52691b4dbfc
parent b634e70a
2011-09-10 Adam Barth <abarth@webkit.org>
Remove DocumentWriter::deprecatedFrameEncoding()
https://bugs.webkit.org/show_bug.cgi?id=67882
Reviewed by Eric Seidel.
Three years ago, in http://trac.webkit.org/changeset/39026, Alexey
Proskuryakov added ContentDispositionEncodingFallbackArray to work
around a web site compatibility issue with a non-ASCII file name
becoming garbled when received in the Content-Disposition header.
Since that time, there has been copious discussion of this topic among
browser vendors, in the IETF, and in the broader web community. For
example, here is a Stack Overflow thread about this topic:
http://stackoverflow.com/questions/93551/how-to-encode-the-filename-parameter-of-content-disposition-header-in-http
Eric Lawrence has written a blog post that summarizes IE's perspective
on this issue:
http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx
The current consensus is that browsers should implement RFC 6266,
which is a new RFC that updates the definition of the
Content-Disposition header. Chrome and Firefox have both implemented
RFC 6266 and have encountered only one issue, which was then fixed by
the web site operator. IE has also implemented RFC 6266, but I don't
have detailed information about their compatibility experience.
This patch add explicit PLATFORM #ifdefs around the quirky
implementation previously used in Apple's Mac and Windows ports. This
code is already only used on Apple's ports, so this patch introduces no
functional changes. It does, however, discourage other ports from
adopting this quirk. IMHO, Apple should remove this quirk as soon as
compatibility allows and converge behavior with the other major browser
vendors.
See bug for manual test (the bug manifests in Safari download UI).
* loader/DocumentWriter.cpp:
* loader/DocumentWriter.h:
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::addExtraFieldsToRequest):
* platform/network/ResourceRequestBase.cpp:
(WebCore::ResourceRequestBase::adopt):
(WebCore::ResourceRequestBase::copyData):
* platform/network/ResourceRequestBase.h:
2011-09-09 Beth Dakin <bdakin@apple.com>
Attempted Leopard build fix.
......@@ -243,6 +243,7 @@ void DocumentWriter::setEncoding(const String& name, bool userChosen)
m_encodingWasChosenByUser = userChosen;
}
#if PLATFORM(MAC) || PLATFORM(WIN)
String DocumentWriter::deprecatedFrameEncoding() const
{
if (m_frame->document()->url().isEmpty())
......@@ -256,6 +257,7 @@ String DocumentWriter::deprecatedFrameEncoding() const
return String();
}
#endif
void DocumentWriter::setDocumentWasLoadedAsPartOfNavigation()
{
......
......@@ -59,10 +59,11 @@ public:
void setEncoding(const String& encoding, bool userChosen);
// FIXME: It's really unforunate to need to expose this piece of state.
// I suspect a better design is to disentangle user-provided encodings,
// default encodings, and the decoding we're currently using.
#if PLATFORM(MAC) || PLATFORM(WIN)
// This code exists only to service a quirk in the Apple Mac and Windows ports.
// FIXME: We should remove this code once CFNetwork implements RFC 6266.
String deprecatedFrameEncoding() const;
#endif
const String& mimeType() const { return m_mimeType; }
void setMIMEType(const String& type) { m_mimeType = type; }
......
......@@ -2540,10 +2540,13 @@ void FrameLoader::addExtraFieldsToRequest(ResourceRequest& request, FrameLoadTyp
// Make sure we send the Origin header.
addHTTPOriginIfNeeded(request, String());
// Always try UTF-8. If that fails, try frame encoding (if any) and then the default.
// For a newly opened frame with an empty URL, encoding() should not be used, because this methods asks decoder, which uses ISO-8859-1.
#if PLATFORM(MAC) || PLATFORM(WIN)
// The Apple Mac and Windows ports have decided not to behave like other
// browsers and instead use a quirky fallback array.
// FIXME: We should remove this code once CFNetwork implements RFC 6266.
Settings* settings = m_frame->settings();
request.setResponseContentDispositionEncodingFallbackArray("UTF-8", activeDocumentLoader()->writer()->deprecatedFrameEncoding(), settings ? settings->defaultTextEncodingName() : String());
#endif
}
void FrameLoader::addHTTPOriginIfNeeded(ResourceRequest& request, const String& origin)
......
......@@ -57,6 +57,7 @@ PassOwnPtr<ResourceRequest> ResourceRequestBase::adopt(PassOwnPtr<CrossThreadRes
request->updateResourceRequest();
request->m_httpHeaderFields.adopt(data->m_httpHeaders.release());
#if PLATFORM(MAC) || PLATFORM(WIN)
size_t encodingCount = data->m_responseContentDispositionEncodingFallbackArray.size();
if (encodingCount > 0) {
String encoding1 = data->m_responseContentDispositionEncodingFallbackArray[0];
......@@ -70,6 +71,7 @@ PassOwnPtr<ResourceRequest> ResourceRequestBase::adopt(PassOwnPtr<CrossThreadRes
ASSERT(encodingCount <= 3);
request->setResponseContentDispositionEncodingFallbackArray(encoding1, encoding2, encoding3);
}
#endif
request->setHTTPBody(data->m_httpBody);
request->setAllowCookies(data->m_allowCookies);
request->doPlatformAdopt(data);
......@@ -87,11 +89,13 @@ PassOwnPtr<CrossThreadResourceRequestData> ResourceRequestBase::copyData() const
data->m_httpHeaders = httpHeaderFields().copyData();
data->m_priority = priority();
#if PLATFORM(MAC) || PLATFORM(WIN)
data->m_responseContentDispositionEncodingFallbackArray.reserveInitialCapacity(m_responseContentDispositionEncodingFallbackArray.size());
size_t encodingArraySize = m_responseContentDispositionEncodingFallbackArray.size();
for (size_t index = 0; index < encodingArraySize; ++index) {
data->m_responseContentDispositionEncodingFallbackArray.append(m_responseContentDispositionEncodingFallbackArray[index].crossThreadString());
}
#endif
if (m_httpBody)
data->m_httpBody = m_httpBody->deepCopy();
data->m_allowCookies = m_allowCookies;
......@@ -271,6 +275,7 @@ void ResourceRequestBase::clearHTTPOrigin()
m_platformRequestUpdated = false;
}
#if PLATFORM(MAC) || PLATFORM(WIN)
void ResourceRequestBase::setResponseContentDispositionEncodingFallbackArray(const String& encoding1, const String& encoding2, const String& encoding3)
{
updateResourceRequest();
......@@ -286,6 +291,7 @@ void ResourceRequestBase::setResponseContentDispositionEncodingFallbackArray(con
if (url().protocolInHTTPFamily())
m_platformRequestUpdated = false;
}
#endif
FormData* ResourceRequestBase::httpBody() const
{
......
......@@ -103,7 +103,11 @@ namespace WebCore {
String httpAccept() const { return httpHeaderField("Accept"); }
void setHTTPAccept(const String& httpAccept) { setHTTPHeaderField("Accept", httpAccept); }
#if PLATFORM(MAC) || PLATFORM(WIN)
// FIXME: This state should either be moved to a CFNetwork-specific
// ResourceRequest or should be removed.
void setResponseContentDispositionEncodingFallbackArray(const String& encoding1, const String& encoding2 = String(), const String& encoding3 = String());
#endif
FormData* httpBody() const;
void setHTTPBody(PassRefPtr<FormData> httpBody);
......@@ -174,7 +178,11 @@ namespace WebCore {
KURL m_firstPartyForCookies;
String m_httpMethod;
HTTPHeaderMap m_httpHeaderFields;
#if PLATFORM(MAC) || PLATFORM(WIN)
// FIXME: This state should either be moved to a CFNetwork-specific
// ResourceRequest or should be removed.
Vector<String> m_responseContentDispositionEncodingFallbackArray;
#endif
RefPtr<FormData> m_httpBody;
bool m_allowCookies;
mutable bool m_resourceRequestUpdated;
......@@ -207,7 +215,9 @@ namespace WebCore {
String m_httpMethod;
OwnPtr<CrossThreadHTTPHeaderMapData> m_httpHeaders;
#if PLATFORM(MAC) || PLATFORM(WIN)
Vector<String> m_responseContentDispositionEncodingFallbackArray;
#endif
RefPtr<FormData> m_httpBody;
bool m_allowCookies;
ResourceLoadPriority m_priority;
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment