[Gtk] Mimetype is NULL with Soup backend

• Component: Page Loading
• Status: RESOLVED FIXED

[Ori Bernstein]

With WebkitGtk from git, head c8611d3830e3006add30b83419ac0f44d00e2cbc, I have been getting freqeunt, but hard to trigger, crashes. I managed to get a backtrace by running Midori in gdb and waiting, but I had a few tabs loading and wasn't sure which page triggered it.

It seems that with the libsoup backend, it seems that occasionally the m_responseMimeType is the null string. The backtrace is attached, and hopefully I'll have a patch soon.

[Ori Bernstein]

Backtrace:

#0  0xb79b8989 in jsRegExpExecute (re=0x83a1120, subject=0x0, length=0, start_offset=0, offsets=0x8323fbc, offsetcount=30)
    at JavaScriptCore/pcre/pcre_exec.cpp:1905
#1  0xb76a8621 in WebCore::RegularExpression::match (this=0xb7f55900, str=@0x842eae0, startFrom=0, matchLength=0x0)
    at WebCore/platform/text/RegularExpression.cpp:132
#2  0xb733c589 in WebCore::DOMImplementation::isXMLMIMEType (mimeType=@0x842eae0)
    at WebCore/dom/DOMImplementation.cpp:329
#3  0xb733ceea in WebCore::DOMImplementation::createDocument (this=0x8210040, type=@0x842eae0, frame=0x82da288, inViewSourceMode=false)
    at WebCore/dom/DOMImplementation.cpp:394
#4  0xb75a2583 in WebCore::FrameLoader::begin (this=0x842e9e8, url=@0x842eb18, dispatch=false, origin=0x0)
    at WebCore/loader/FrameLoader.cpp:916
#5  0xb75b150c in WebCore::FrameLoader::receivedFirstData (this=0x842e9e8)
    at WebCore/loader/FrameLoader.cpp:846
#6  0xb75b2081 in WebCore::FrameLoader::setEncoding (this=0x842e9e8, name=@0xbfce4008, userChosen=false)
    at WebCore/loader/FrameLoader.cpp:1747 
#7  0xb6f70cff in WebKit::FrameLoaderClient::finishedLoading (this=0x838ac28, documentLoader=0x8451470)
    at WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp:636
#8  0xb759669e in WebCore::FrameLoader::finishedLoadingDocument (this=0x842e9e8, loader=0x8451470)
    at WebCore/loader/FrameLoader.cpp:2860
#9  0xb75901a6 in WebCore::DocumentLoader::finishedLoading (this=0x8451470)
    at WebCore/loader/DocumentLoader.cpp:312
#10 0xb75a8a6b in WebCore::FrameLoader::finishedLoading (this=0x842e9e8) at WebCore/loader/FrameLoader.cpp:2804
#11 0xb75d97c9 in WebCore::MainResourceLoader::didFinishLoading (this=0x843dd00)
    at WebCore/loader/MainResourceLoader.cpp:310
#12 0xb75e4ab1 in WebCore::ResourceLoader::didFinishLoading (this=0x843dd00)
    at WebCore/loader/ResourceLoader.cpp:372
#13 0xb77dea91 in dataCallback (session=0x81eaf28, msg=0x825c780, data=0x83a0028)
    at WebCore/platform/network/soup/ResourceHandleSoup.cpp:77
#14 0xb6122916 in ?? () from /usr/lib/libsoup-2.4.so.1

[Ori Bernstein]

Created attachment 19861 [details]
Set a default mimetype 

Here's a patch that I believe will fix the crash, although I would need more testing to be sure, and I'm not entirely certain it is the correct fix, since the sites I was loading when Midori crashed were definitely not text/plain type.

[Tommi Komulainen]

IIRC lack of Content-Type HTTP header should be treated as application/octet-stream rather than text/plain. Should be mentioned in the HTTP RFC.

[Mark Rowe (bdash)]

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

[Mark Rowe (bdash)]

The patch matches what is in the curl backend, but appears wrong given the HTTP 1.1 specification quoted above.

[Eric Seidel (no email)]

Comment on attachment 19861 [details]
Set a default mimetype 

This needs a comment and a changelog.  The comment should explain that this is normal behavior for soup to return n empty string to mean text/plain or whatever this change is actually supposed to be fixing.

[Alexey Proskuryakov]

See also: bug 20257 (using curl).

[Gustavo Noronha (kov)]

I believe this problem has gone away after this: http://trac.webkit.org/changeset/41481.

I'm closing on that basis, but if you think there's still something to be done, please reopen.