Bug 71751 - Content-type detection cannot be overridden for unknown type application/x-formproc
Summary: Content-type detection cannot be overridden for unknown type application/x-fo...
Status: RESOLVED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-03 15:20 UTC by Ralf Holzer
Modified: 2008-05-04 23:07 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch for http.cc / no headers problem (1.19 KB, patch)
2004-04-24 23:33 UTC, Ralf Holzer
Details
python script that acts like the buggy site (668 bytes, application/x-compressed-tar)
2008-05-04 23:07 UTC, Daniel Winter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Holzer 2004-01-03 15:20:15 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7) 

I am trying to view a badly designed website which sends a content type of application/x-formproc for a form that returns an html document. Konquerror detects text/plain as the content-type and
it is impossible to manually set it to view the page as html.

The form posts via SSL to a CGI script at:

https://acis.as.cmu.edu/sio/proc.formproc
(sorry, the page is password protected).

I have created a file association for application/x-formproc, for all extensions with *.formproc
and selected to view it using the embedded KHTML part. The html page contains no content-type
information at all. It is still detected as text/plain. I am aware that the page is sending
a wrong content-type, but it should still be possible to override it manually. It seems that
Mozilla and IE default to viewing unknown content types as html. Is that an option?

Here is the debug output:

kparts: 0x83308c8 emitting activePartChanged 0x84cf150
khtml (part): new active frame 0x84cf150
khtml: 0x84cf150: KHTMLPart::submitForm target=body url=proc.formproc
khtml (part): Running new KHTMLRun for 0x82b9268 and child=0x84cb4e8
konqueror: [void KonqView::setLoading(bool, bool)] loading=true hasPending=false
konqueror: [void KonqView::setLoading(bool, bool)] loading=true hasPending=false
kparts: BrowserRun::scanfile https://acis.as.cmu.edu/sio/proc.formproc
kparts: slotBrowserMimetype: found text/plain for https://acis.as.cmu.edu/sio/proc.formproc
kio (KIOJob): Job::kill this=0x84ead88 m_progressId=0 quietly=true
khtml (part): saveState!
khtml (part): KHTMLPart::saveState saving URL https://acis.as.cmu.edu/sio/
khtml (part): saveState!
khtml (part): KHTMLPart::saveState saving URL https://acis.as.cmu.edu/sio/mast.shtml
khtml (part): saveState!
khtml (part): KHTMLPart::saveState saving URL https://acis.as.cmu.edu/sio/eye.html
Comment 1 Dawit Alemayehu 2004-01-10 09:51:19 UTC
If no Content-Type header is sent by the server, then KDE's http io-slave first attempts to determine it from the data sent by looking at the first 1024 bytes. If that fails, it then uses the default mime-type which is text/html.
In your case, the mime-type detector simply detects the data as text/plain. As such whatever you did to try and resolve this issue does not make a difference. There is no way to override this...
Comment 2 Ralf Holzer 2004-01-11 05:39:11 UTC
The server does send a content type header (application/x-formproc). And
the first 1024 bytes of data are definitely HTML content. Here's the content
(it starts with two newlines):


<HTML>
<HEAD>
<TITLE> Schedule for Spring 2004 </TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFCC>
<form action="proc.formproc" method="post">
<input type="hidden" name="ARGNUM" value=1>
<input type="hidden" name="FUNCNAME" value="schedule">
<input type="hidden" name="PORT" value=10>
Would you like your schedule for a different semester?
<select name="VAR1">
<option>Fall 2003
</select>
 <input type="submit" Value="Submit">
 <p>
 <H2>Schedule for Spring 2004</H2>
 <P>
 <pre>
personal stuff goes here
 </pre>
 <P>
 <P>
 <b>To print the information:</b> Click in this area then select Print Frame from the File menu.<P>
 <a href="schedule_policies.html">Related Policies</a>
 <P>
 <P>
 <A HREF="index.html" TARGET="_top"><IMG SRC="exit.eye.gif" Height=40 Width=55 Border=0 ALT="EXIT"></A>
 <A HREF="http://www.cmu.edu/" TARGET="_top"><IMG SRC="cmu.logo.gif" Border=0 ALT="CMU Home"></A>
 <A HREF="http://www.cmu.edu/hub/" TARGET="_top"><IMG SRC="hub.gif" Border=0 Height=40 Width=43 ALT="HUB Home"></A>
 </BODY>
 </HTML>
Comment 3 Ralf Holzer 2004-04-24 23:30:15 UTC
The problem on this page is that the server sends absolutely no header at all, not even an HTTP response header. It just sends two newlines and then the <HTML> tag. 

The http kioslave is currently checking for this case, but only when it receives the HTTP response header and no other headers after that. I attached a patch that fixes this and sets the mime type to text/html. Since the response starts with a tag, that should be ok.
Comment 4 Ralf Holzer 2004-04-24 23:33:55 UTC
Created attachment 5767 [details]
Patch for http.cc / no headers problem
Comment 5 Daniel Winter 2008-05-04 22:49:20 UTC
Seemes fixed in konqueror 4 svn trunk revision r803532.

Attached a small python script, which acts as a buggy webserver which sends out a index.html (use http://localhost:9000/test.formproc) without any http header and content typ.

Current Konqueror shows it as html.
Comment 6 Daniel Winter 2008-05-04 23:07:37 UTC
Created attachment 24633 [details]
python script that acts like the buggy site