"Content-Type: 5a Filter sel. Text Types" Issue

[whenever]

If you visit http://club.china.com/data/thread/1011/2...0/5_1.html using Opera 11.5, you will see a download dialog.

The problem comes from a request to http://r.club.china.com/SoundOfSilence?f...=271117005 from that page.

Proxomitron bypassed:

Code:

+++RESP 17077+++
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 30 Jun 2011 09:55:38 GMT
Connection: keep-alive
Content-Length: 0

Proxomitron effective with sidki filter set:

Code:

RESP 17055 : Content-Type: Filter True:

+++RESP 17055+++
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 30 Jun 2011 09:50:31 GMT
Connection: keep-alive
Content-Length: 0
Cache-Control: public, max-age=86400
Content-Type: ; PrxMsg: Filter Text: No Content-Type
Last-Modified: Thu, 30 Jun 2011 09:50:32 GMT; PrxMsg: added
|.*.URL-ID: (17055) http://r.club.china.com/SoundOfSilence?forumid=1011&threadid=271117005

The added Content-Type: ; PrxMsg: Filter Text: No Content-Type caused the download dialog for Opera, but not for IE 8 and Firefox 5.

It seems an older version of IE should have that problem in the past because sidki has below code:

Code:

($TST(hOrigUA=*msie(^*opera)*)$SET(1=text/plain)|)

But since Opera is the only browser (Safari and Chrome not tested ) who suffered that problem now, we can change it to:

Code:

($TST(hOrigUA=*opera*)$SET(1=text/plain)|)

The full modified filter:

Code:

[HTTP headers]
In = TRUE
Out = FALSE
Key = "Content-Type: 5a Filter sel. Text Types     09.05.14 [sd] (d.r l.3) (In) TEST"
URL = "^$RESP(204|3|*No headers$TST(uPort=:(^443)*))|$TST(hRealCT=*)|$TST(keyword=*.(a_headers|a_type_t|i_level:[12]).*)|$TST(volat=*.post:1.*)|$TST(uExt=exe|gz)"
Match = "text/plain(^*; Prx(^Msg: Fixed acc. to Original))$SET(1=\0)|(\*/\*$SET(2=: \0)|(^?)$SET(2=: No Content-Type))($TST(hOrigUA=*opera*)$SET(1=text/plain)|)&\0&($TST(volat=*.log:2*)$ADDLST(Log-Main,[$DTM(d T)]\tHDR_In CT_FilterTrue\t\1\2 \t\u)|)($TST(\0=\**)$TST(volat=*.log:[12]c.*)$ADDLST(Log-Rare,HDR_In CT_FilterTrue\t\1\2 \t\u)|)$LOG(CRESP $DTM(c) : Content-Type: Filter True: \1)"
Replace = "\1; PrxMsg: Filter Text\2$SET(hRealCT=filter)$FILTER(1)"

[JJoe]

Confirmed. Chrome appears to be OK. Safari not tested.

What is gained by removing the exception for msie? I still have computers that use IE7, IE6, and whatever is on my Win95 machine.

Thanks

[whenever]

I don't have computers that uses IE6/7. Could you give them a test?

Maybe we have to keep the exception for msie.

[zoltan]

I'm not even sure about the purpose of this filter, but it seems to be causing issues on this page. Clicking the media file for Feb 9 should produce a save/dialog box, but when 5a Filter sel. Text Types is checked it attempts to show it as text, at least in Firefox.

[JJoe]

(Feb. 17, 2012 01:30 AM)zoltan Wrote:  I'm not even sure about the purpose of this filter, but it seems to be causing issues on this page. Clicking the media file for Feb 9 should produce a save/dialog box, but when 5a Filter sel. Text Types is checked it attempts to show it as text, at least in Firefox.

By default, the Proxomitron does not filter all files. This filter forces filtering of some "text/plain" type files.

The darkhorizonsradio server is sending a "Content-Type: text/plain" for m4a files. I think, it should send "Content-Type: audio/x-m4a".

An Exceptions-U.ptxt entry like

Code:

www.darkhorizonsradio.com/podcasts/shows/Dark_Horizons_[0-9]+.m4a $SET(0=a_type_t.)

may avoid the problem at darkhorizonsradio.


This filter

Code:

[HTTP headers]
In = TRUE
Out = FALSE
Key = "Content-Type:   1 test  "
Match = "text/plain$URL(http://www.darkhorizonsradio.com/podcasts/shows/Dark_Horizons_[0-9]+.m4a)"
Replace = "audio/x-m4a"

should correct the Content-Type and solve your problem? If so, we could consider an addition to "MIME-List.ptxt".

Regardless, the "Content-Type: 5a Filter sel. Text Types" filter is adding some info to the Content-Type header and this appears to trigger the behavior that you reported.

Code:

Content-Type: text/plain; PrxMsg: Filter Text.

HTH

[zoltan]

Thanks. The Exceptions entry and the filter each solves the problem. For my purposes, it's not that big of a deal now that I know what it's doing and how to stop it with an Exception. Or is the filter preferable? I'm thinking this isn't very common, although I seem to remember jpegs being shown as text at times but never thought of it as being a proxomitron issue.

[JJoe]

(Feb. 18, 2012 04:04 AM)zoltan Wrote:  Or is the filter preferable?

I'm not sure. Use the Exceptions entry.

The test filter was to gain info. Correcting darkhorizonsradio's 'mistake', if it is a mistake, doesn't seem to have any bad consequences. I'll put a note in "MIME-List.ptxt" for later.

Have fun

[sbk]

(Jul. 01, 2011 04:16 AM)JJoe Wrote:  I still have computers that use IE7, IE6, and whatever is on my Win95 machine.

ns3? Mosaic?

I've noticed rarely when using firefox "View Image" on a jpg, that the browser gives me a download dialog, instead of displaying the jpg.
I assume this indicates incorrect mime type, but haven't looked at proxo log to see if really has been incorrect mime type.

(irfanview checks for true filetype, and offers to rename filetype when mismatch, but this is for image files already on the hard drive)