On Tue, Jun 14, 2005 at 01:36:49PM -0400, [EMAIL PROTECTED] wrote:
> At 05:01 PM 6/14/2005 +0100, Ian Clarke wrote:
> >* Replies will be sent through Spamex to [email protected]
> >* For additional info click -> http://www.spamex.com/i/?v=6762337
> >
> >Here is the response I sent separately:
> >
> >I didn't discover the Opera problem, but the general issue is that
> >Freenet can't send data to a web browser unless it knows what the web
> >browser will do with it, otherwise the web browser could do something
> >that would compromise your anonymity (such as connect to a remote web
> >server without going through Freenet).  For this reason Freenet
> >limits the mime-types that can be sent to the browser.
> >
> >Internet Explorer, and apparently Opera attempt to guess mime-types
> >for some types of data in a way that Freenet can't reasonably
> >anticipate, and thus for a given object Freenet may not be able to
> >determine whether it is safe to send it to the browser.
> >
> >If Opera no-longer does this, or if there is some reasonable way to
> >guarantee that Opera will treat a given piece of data as the mime- type 
> >specified in the HTTP headers (without Freenet needing to do an
> >unreasonable analysis of the data itself), then this information is
> >no-longer correct and we will update Freenet accordingly.
> One of Opera's developers responded in the thread I linked to in my last 
> e-mail. Since I don't know if anyone here is following the forum thread, 
> I'll also quote the response here:
> 
> by
> yngve
> Senior Developer
> 
> In 7.2x (IIRC, or 7.50) we restricted the scope of our guessing algorithm. 
> This was done to resolve several problems with incorrect gussing.
> 
> Previously both application/octet-stream and text/plain were sent through 
> the guessing algorithm (first extension, then check content)
> 
> Now, only three text/plain variants (the various defaults used by badly 
> configured servers) are checked to see if they look like binary content, 
> which will be changed to application/octet-stream (final) and (by default) 
> ask the user what to do and where to place it.

Which variants?
> 
> Application/octet-stream will first go through an extension check and if it 
> matches a known type it will be handles like that entry specifies (e.g. 
> .swf files are flash content), if it does not match an extension we take a 
> look at the content to see if it looks like an image, HTML, XML or text 
> file and in that case render it as one of those. Otherwise we ask the user 
> what to do and where to place it. This method was also used for text/plain 
> before we changed the guessing algorithm.

Okay, here we have a problem. At the moment we assume that
application/octet-stream means "download to disk somewhere".
> 
> If the server does not send a MIME type the document is handled like 
> application/octet-stream above.
> 
> Any other MIME type is handled according to the preferences set by the user 
> for that type or we ask the user.
> 
> If the freenet developers object to Opera rendering 
> application/octet-stream content that looks like HTML as HTML they probably 
> have the option of overriding the MIME type to something that will force a 
> download (beside specifying a "Content-Disposition: attachment") , e.g. 
> application/x-msdownload or application/x-unknown, or something similar. Of 
> course, if I understand it correctly, that approach may not work with IE.

Okay, that's a good idea - what's wrong with Content-Disposition:
attachment ?

So what we need to do:
- Find out which version of Opera the guessing scheme changed
- Detect old Opera variants and tell the user to upgrade or change the
  config
- Use some means beyond application/octet-stream to specify that a file
  must be downloaded to disk
- Look into the text/plain issue above.

> Sincerely,
> Yngve Pettersen
> Opera Software 
-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Support mailing list
[email protected]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

Reply via email to