"nak" <a@a.com> wrote in message
news:13CA4579-7BBA-498D-AB56-DFAD2A5315CD@microsoft.com...
> Hey there,
>
>    I'm sending a file to the remote pc via web service call.  I am doing
> this via the following code,
>
>    HttpContext.Current.Response.ContentType =
> "application/mycustommimetype"
>    HttpContext.Current.Response.AddHeader("Content-Disposition",
> "attachment; filename=somefilename.pop")
>    HttpContext.Current.Response.AddHeader("Content-Length",
> mystring.Length.ToString())
>    HttpContext.Current.Response.Write(mystring)
>    HttpContext.Current.Response.Flush()
>    HttpContext.Current.Response.End()
>
>    This works, but at current IE is giving me the option to either Open it
> or Save it.  I would like automatically open it, in the same way that
> Windows Media Player opens an mp3 automatically when clicked on a page.
>
>    Is this down to my ContentType?  I did try "application/octet-stream"
> but this kept telling IE that the file was a HTML document, when it isn't
> so it would only open it in the browser, or save it.
>
>    Many thanks in advance!
>
> Nick.
>
>

> Hey there,
>
>    I'm sending a file to the remote pc via web service call.  I am doing
> this via the following code,
>
>    HttpContext.Current.Response.ContentType =
> "application/mycustommimetype"
>    HttpContext.Current.Response.AddHeader("Content-Disposition",
> "attachment; filename=somefilename.pop")
>    HttpContext.Current.Response.AddHeader("Content-Length",
> mystring.Length.ToString())
>    HttpContext.Current.Response.Write(mystring)
>    HttpContext.Current.Response.Flush()
>    HttpContext.Current.Response.End()
>
>    This works, but at current IE is giving me the option to either Open
> it or Save it.  I would like automatically open it, in the same way that
> Windows Media Player opens an mp3 automatically when clicked on a page.
>
>    Is this down to my ContentType?  I did try "application/octet-stream"
> but this kept telling IE that the file was a HTML document, when it
> isn't so it would only open it in the browser, or save it.
>
>    Many thanks in advance!
>
> Nick.
>

> When you register, then it will be part of the FILE ASSOCIATION on the PC.
> You can see these associations with the DOS Commands:
>
>    FTYPE
>    ASSOC
>
> Type
>
>    FTYPE /?
>
> For a complete explanation and example.
>
> You can use these commands *HOWEVER* that doesn't get the MIME TYPE
> (application/mycustommimetype) resolved required for the browser.
>
> That is done via the registry and there are several keys to set to make it
> work for all browsers, i.e. Netscape, Mozilla based and IE, etc.

> Hi Mike,
>
>> You need to register the MIME type and extension on the PC.
>
>    Indeed, and it already is, so far I have...
>
>    ---------
>
>    HKCR\Mime\Database\Content Type\application/foobar-myfile
>
>    HKCR\.fbmf\[Default - foobar.myfile]
>
>    HKCR\foobar.myfile\[Default - Foobar File]
>    HKCR\foobar.myfile\Shell\Open\Command\[Default - app path "%1"]
>    HKCR\foobar.myfile\DefaultIcon\[Default = app path]
>
>    HKLM\Software\Microsoft\Windows\CurrentVersion\Internet
> Settings\Secure Mime Handlers\[foobar.myfile - REG_SZ]
>
>    ---------
>
>    The file type is associating and the app icon appears, but still no
> option to open automatically.
>
>> When you register, then it will be part of the FILE ASSOCIATION on the
>> PC. You can see these associations with the DOS Commands:
>>
>>    FTYPE
>>    ASSOC
>>
>> Type
>>
>>    FTYPE /?
>>
>> For a complete explanation and example.
>>
>> You can use these commands *HOWEVER* that doesn't get the MIME TYPE
>> (application/mycustommimetype) resolved required for the browser.
>>
>> That is done via the registry and there are several keys to set to
>> make it work for all browsers, i.e. Netscape, Mozilla based and IE, etc.
>
>    I believe that's what I have set up at current, the associations will
> be done on installation of the application, so I won't need to be using
> any dos commands.
>
>> I have C/C++ code to show you how to register it. I can give ya that
>> if that will help?   Here is a BUG report I issued last year for the
>> Google's Chrome  browser that had a bug with this stuff.   I
>> posted an example registration program for the Chrome developers to
>> repeat it.
>>
>>     http://code.google.com/p/chromium/issues/detail?id=2292
>>
>> Look for the wcChromeApplet.Cpp download.
>>
>> That (the registry logic) should be very easy to port to VB.NET,.
>
>    I'll check out the cpp file and see what registry keys I'm missing.
> Cheers for your help.
>
> Nick.

"Mike" <unkn***@unknown.tv> wrote in message
news:ejL#vjS5JHA.140@TK2MSFTNGP03.phx.gbl...
> This cross my mind with your description of the behavior.
>
> Chrome and I believe IE8 (could be IE9) have been following each other on
> new ways to start pages using a  new PROCESS rather than new THREAD for
> tabs and windows.
>
> The bug if I recall had do to with attempt to sandbox security but Chrome
> has a mismatch in what was being checked in the logic so it failed to
> spawn the client side application.
>
> Perhaps, Maybe, just suggesting the possibility, the IE8 people copied the
> Chrome open source for this logic and hence the bug? <g>  I don't have IE8
> installed to check that out.
>
> The behavior in Chrome was like you describe, registered, Icon appears etc
> and it even highlighted the association, but it would not spawn the
> client-side applet.
>
> No problem with other browsers.  We use this for our free Wildcat!
> Navigator (wcNAV) GUI frontend designed for our application server. It
> runs standalone but it also allows the web operator to create HTML pages
> and links to launch the wcNAV GUI clients - like a menu bar, etc.  Users
> have the option to login via HTML Display mode or WCNAV Display GUI mode.
>
> --
>
>
> nak wrote:
>> Hi Mike,
>>
>>> You need to register the MIME type and extension on the PC.
>>
>>    Indeed, and it already is, so far I have...
>>
>>    ---------
>>
>>    HKCR\Mime\Database\Content Type\application/foobar-myfile
>>
>>    HKCR\.fbmf\[Default - foobar.myfile]
>>
>>    HKCR\foobar.myfile\[Default - Foobar File]
>>    HKCR\foobar.myfile\Shell\Open\Command\[Default - app path "%1"]
>>    HKCR\foobar.myfile\DefaultIcon\[Default = app path]
>>
>>    HKLM\Software\Microsoft\Windows\CurrentVersion\Internet
>> Settings\Secure Mime Handlers\[foobar.myfile - REG_SZ]
>>
>>    ---------
>>
>>    The file type is associating and the app icon appears, but still no
>> option to open automatically.
>>
>>> When you register, then it will be part of the FILE ASSOCIATION on the
>>> PC. You can see these associations with the DOS Commands:
>>>
>>>    FTYPE
>>>    ASSOC
>>>
>>> Type
>>>
>>>    FTYPE /?
>>>
>>> For a complete explanation and example.
>>>
>>> You can use these commands *HOWEVER* that doesn't get the MIME TYPE
>>> (application/mycustommimetype) resolved required for the browser.
>>>
>>> That is done via the registry and there are several keys to set to make
>>> it work for all browsers, i.e. Netscape, Mozilla based and IE, etc.
>>
>>    I believe that's what I have set up at current, the associations will
>> be done on installation of the application, so I won't need to be using
>> any dos commands.
>>
>>> I have C/C++ code to show you how to register it. I can give ya that if
>>> that will help?   Here is a BUG report I issued last year for the
>>> Google's Chrome  browser that had a bug with this stuff.   I
>>> posted an example registration program for the Chrome developers to
>>> repeat it.
>>>
>>>     http://code.google.com/p/chromium/issues/detail?id=2292
>>>
>>> Look for the wcChromeApplet.Cpp download.
>>>
>>> That (the registry logic) should be very easy to port to VB.NET,.
>>
>>    I'll check out the cpp file and see what registry keys I'm missing.
>> Cheers for your help.
>>
>> Nick.
>

> Hi Mike
>
>    I'm not entirely sure this could be a bug tbh, I mean this
> functionality has been a part of IE way before Chrome was even around,
> so I'm not sure Microsoft would have the need to go pillaging some open
> source code.
>
>    Also, I just installed BitTorrent, one app that I know can do exactly
> what I'm trying to do, and indeed it does, via a .torrent file with a
> mime type of application/x-bittorrent
>
>    I have started going through the registry to see if they have done
> anything different, so far I have noticed a few more Content Type
> keys/values dotted about the place but tbh I'm not entirely sure they
> are necessary, more like they put them in there just incase lol!  But I
> will find out what they have done that I haven't and report my findings
> back here.
>
> Nick.
>
> "Mike" <unkn***@unknown.tv> wrote in message
> news:ejL#vjS5JHA.140@TK2MSFTNGP03.phx.gbl...
>> This cross my mind with your description of the behavior.
>>
>> Chrome and I believe IE8 (could be IE9) have been following each other
>> on new ways to start pages using a  new PROCESS rather than new THREAD
>> for tabs and windows.
>>
>> The bug if I recall had do to with attempt to sandbox security but
>> Chrome has a mismatch in what was being checked in the logic so it
>> failed to spawn the client side application.
>>
>> Perhaps, Maybe, just suggesting the possibility, the IE8 people copied
>> the Chrome open source for this logic and hence the bug? <g>  I don't
>> have IE8 installed to check that out.
>>
>> The behavior in Chrome was like you describe, registered, Icon appears
>> etc and it even highlighted the association, but it would not spawn
>> the client-side applet.
>>
>> No problem with other browsers.  We use this for our free Wildcat!
>> Navigator (wcNAV) GUI frontend designed for our application server. It
>> runs standalone but it also allows the web operator to create HTML
>> pages and links to launch the wcNAV GUI clients - like a menu bar,
>> etc.  Users have the option to login via HTML Display mode or WCNAV
>> Display GUI mode.
>>
>> --
>>
>>
>> nak wrote:
>>> Hi Mike,
>>>
>>>> You need to register the MIME type and extension on the PC.
>>>
>>>    Indeed, and it already is, so far I have...
>>>
>>>    ---------
>>>
>>>    HKCR\Mime\Database\Content Type\application/foobar-myfile
>>>
>>>    HKCR\.fbmf\[Default - foobar.myfile]
>>>
>>>    HKCR\foobar.myfile\[Default - Foobar File]
>>>    HKCR\foobar.myfile\Shell\Open\Command\[Default - app path "%1"]
>>>    HKCR\foobar.myfile\DefaultIcon\[Default = app path]
>>>
>>>    HKLM\Software\Microsoft\Windows\CurrentVersion\Internet
>>> Settings\Secure Mime Handlers\[foobar.myfile - REG_SZ]
>>>
>>>    ---------
>>>
>>>    The file type is associating and the app icon appears, but still
>>> no option to open automatically.
>>>
>>>> When you register, then it will be part of the FILE ASSOCIATION on
>>>> the PC. You can see these associations with the DOS Commands:
>>>>
>>>>    FTYPE
>>>>    ASSOC
>>>>
>>>> Type
>>>>
>>>>    FTYPE /?
>>>>
>>>> For a complete explanation and example.
>>>>
>>>> You can use these commands *HOWEVER* that doesn't get the MIME TYPE
>>>> (application/mycustommimetype) resolved required for the browser.
>>>>
>>>> That is done via the registry and there are several keys to set to
>>>> make it work for all browsers, i.e. Netscape, Mozilla based and IE,
>>>> etc.
>>>
>>>    I believe that's what I have set up at current, the associations
>>> will be done on installation of the application, so I won't need to
>>> be using any dos commands.
>>>
>>>> I have C/C++ code to show you how to register it. I can give ya that
>>>> if that will help?   Here is a BUG report I issued last year for the
>>>> Google's Chrome  browser that had a bug with this stuff.   I
>>>> posted an example registration program for the Chrome developers to
>>>> repeat it.
>>>>
>>>>     http://code.google.com/p/chromium/issues/detail?id=2292
>>>>
>>>> Look for the wcChromeApplet.Cpp download.
>>>>
>>>> That (the registry logic) should be very easy to port to VB.NET,.
>>>
>>>    I'll check out the cpp file and see what registry keys I'm
>>> missing. Cheers for your help.
>>>
>>> Nick.
>>

> Hi Mike,
>
>> Nick, don't recall you mentioning if you tried your code with other
>> browsers, like IE6/7, FireFox, OPERA, K-Meleon, Safari for Windows.
>
>    Well unfortunately, due to recent changes in the security model of HTML
> controls I can't test in any other browser.  Currently Internet Explorer
> is the only browser that treats the Input control differently when the
> site is added to a trusted sites list, none of the other browsers do that.
> The main knock on effect of this means we can't obtain the full path from
> the Input control, we use the full path as we don't upload anything to the
> site, merely use the filename as reference before everything else gets
> kicked off.
>
>> Don't be surprise of the mindset of the new generation programmers who
>> are raised in the last 10 years of open source availability.  For sure,
>> MS has followed Chrome in the direction in how web pages are managed
>> using a multi-process model vs multi-thread under one process approach.
>> There is a big "claim" by both to the performance and sandbox security
>> gains, but also much to do with the direction of multi-core
>> HyperThreading, lots of memory machine availability that allow the system
>> to handle it better with these much bigger applications - oops, OS like
>> applications. :-)
>>
>> So did the MS people "peeked" at the Chrome Open source?
>
>    Well just because both have implemented a security feature, doesn't
> mean any code was stolen.  It's easy to hear a simple explanation of how
> an application works then get some people together to do a bit of
> brainstorming in order to come up with your own solution.
>
>    I'm sure Microsoft have done it in the past, but this particular
> feature of custom mime types is not new and I would be surprised if they
> managed to break it by using stolen source which is buggy, considering it
> does actually work (bittorrent for example).
>
>    Anyway, Google Chrome wasn't written from scratch...
>
>> Who knows? <g>  If an engineer was asked "Do the same thing", today,
>> people look at existing methods and approaches and its open source, well,
>> why not look at it?  It isn' like the old clean box lab eras or the
>> strong reverse engineering restriction days.
>>
>> In any case, if the behavior is the same in other browsers then more than
>> likely, its a problem in the registration.  If its just a one or few
>> browsers, we need to roll up the sleeves and figure it out. :-)
>
>    I'm just trying to figure it out at the moment as I'm not convinced
> it's registry problems, I think it's the response the server is sending.
> But I shall update as soon as I know more.
>
> Nick.
>
>

> Hi Patrice,
>
>> Yes, this is a client side setting for your mime type. So not sure how
>> your application is installed client side but you could enable this
>> during setup...
>
>    My last test proved this to not be the case.  I made a web service
> that dishes out a ".torrent" file of the correct MIME type in the same
> way that I am serving my own file.  But it does *not* act in the same
> way as simply pulling a file from a web page.  It offers no
> functionality of treating the file with any automatic behavior.  I think
> at the moment it is recognising the file via extension, and not by MIME
> type, I can also back this up by removing MIME information from the
> registry and it still works.
>
>    I think it might have something to do with the Cache Control
> parameter. I have read that it should be set to "no-transfer" in order
> to prevent IE from guessing the MIME type of an attachment. 
> Unfortunately .NET doesn't seem to let me change it to this and other
> settings seem to have no effect.
>
>    In the morning I am going to simply compare a working set of headers
> to the headers that do not work, and that should provide the answer.
>
>    I'll update...
>
> Nick.

"Mike" <unkn***@unknown.tv> wrote in message
news:ujKr2yW5JHA.3968@TK2MSFTNGP03.phx.gbl...
> IE has a history of issues with the cache related control headers.  To
> resolve, many HTTP request logics, like AJAX for example, will add a
>
>            &unique_name=some_unique_counter
>
> to the request for one reason - to force IE to make the request.
>
> --
>
> nak wrote:
>> Hi Patrice,
>>
>>> Yes, this is a client side setting for your mime type. So not sure how
>>> your application is installed client side but you could enable this
>>> during setup...
>>
>>    My last test proved this to not be the case.  I made a web service
>> that dishes out a ".torrent" file of the correct MIME type in the same
>> way that I am serving my own file.  But it does *not* act in the same way
>> as simply pulling a file from a web page.  It offers no functionality of
>> treating the file with any automatic behavior.  I think at the moment it
>> is recognising the file via extension, and not by MIME type, I can also
>> back this up by removing MIME information from the registry and it still
>> works.
>>
>>    I think it might have something to do with the Cache Control
>> parameter. I have read that it should be set to "no-transfer" in order to
>> prevent IE from guessing the MIME type of an attachment.  Unfortunately
>> .NET doesn't seem to let me change it to this and other settings seem to
>> have no effect.
>>
>>    In the morning I am going to simply compare a working set of headers
>> to the headers that do not work, and that should provide the answer.
>>
>>    I'll update...
>>
>> Nick.
>

"nak" <a@a.com> wrote in message
news:13CA4579-7BBA-498D-AB56-DFAD2A5315CD@microsoft.com...
> Hey there,
>
>    I'm sending a file to the remote pc via web service call.  I am doing
> this via the following code,
>
>    HttpContext.Current.Response.ContentType =
> "application/mycustommimetype"
>    HttpContext.Current.Response.AddHeader("Content-Disposition",
> "attachment; filename=somefilename.pop")
>    HttpContext.Current.Response.AddHeader("Content-Length",
> mystring.Length.ToString())
>    HttpContext.Current.Response.Write(mystring)
>    HttpContext.Current.Response.Flush()
>    HttpContext.Current.Response.End()
>
>    This works, but at current IE is giving me the option to either Open it
> or Save it.  I would like automatically open it, in the same way that
> Windows Media Player opens an mp3 automatically when clicked on a page.
>
>    Is this down to my ContentType?  I did try "application/octet-stream"
> but this kept telling IE that the file was a HTML document, when it isn't
> so it would only open it in the browser, or save it.
>
>    Many thanks in advance!
>
> Nick.
>

"Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message
news:#VSKHOb5JHA.4936@TK2MSFTNGP04.phx.gbl...
> Hi Nick,
>
> As forever I'm not understanding what you are trying to achieve.
>
> However, reading the thread I got the idea that this could maybe a
> solution for you.
>
> Not exactly, but you are clever enough to translate it to your problem as
> it fits slightly
>
> http://www.vb-tips.com/ServerClock.aspx
>
> Cor
>
>
> "nak" <a@a.com> wrote in message
> news:13CA4579-7BBA-498D-AB56-DFAD2A5315CD@microsoft.com...
>> Hey there,
>>
>>    I'm sending a file to the remote pc via web service call.  I am doing
>> this via the following code,
>>
>>    HttpContext.Current.Response.ContentType =
>> "application/mycustommimetype"
>>    HttpContext.Current.Response.AddHeader("Content-Disposition",
>> "attachment; filename=somefilename.pop")
>>    HttpContext.Current.Response.AddHeader("Content-Length",
>> mystring.Length.ToString())
>>    HttpContext.Current.Response.Write(mystring)
>>    HttpContext.Current.Response.Flush()
>>    HttpContext.Current.Response.End()
>>
>>    This works, but at current IE is giving me the option to either Open
>> it or Save it.  I would like automatically open it, in the same way that
>> Windows Media Player opens an mp3 automatically when clicked on a page.
>>
>>    Is this down to my ContentType?  I did try "application/octet-stream"
>> but this kept telling IE that the file was a HTML document, when it isn't
>> so it would only open it in the browser, or save it.
>>
>>    Many thanks in advance!
>>
>> Nick.
>>
>
>

> All sorted now, as mentioned in my reply to Mike, my code needed to read
> something along the lines of...
>
> HttpContext.Current.Response.ContentType = "application/x-bittorrent"
> HttpContext.Current.Response.AddHeader("Accept-Ranges", "bytes")
> HttpContext.Current.Response.AddHeader("Content-Length",
> myfilecontents.Length.ToString())
> HttpContext.Current.Response.Write(myfilecontents)
> HttpContext.Current.Response.Flush()
> HttpContext.Current.Response.End()
>
> IE now throws the file straight at BitTorrent or the associated MIME app
> without asking any more questions, perfect!
>
> "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message
> news:#VSKHOb5JHA.4936@TK2MSFTNGP04.phx.gbl...
>> Hi Nick,
>>
>> As forever I'm not understanding what you are trying to achieve.
>>
>> However, reading the thread I got the idea that this could maybe a
>> solution for you.
>>
>> Not exactly, but you are clever enough to translate it to your problem
>> as it fits slightly
>>
>> http://www.vb-tips.com/ServerClock.aspx
>>
>> Cor
>>
>>
>> "nak" <a@a.com> wrote in message
>> news:13CA4579-7BBA-498D-AB56-DFAD2A5315CD@microsoft.com...
>>> Hey there,
>>>
>>>    I'm sending a file to the remote pc via web service call.  I am
>>> doing this via the following code,
>>>
>>>    HttpContext.Current.Response.ContentType =
>>> "application/mycustommimetype"
>>>    HttpContext.Current.Response.AddHeader("Content-Disposition",
>>> "attachment; filename=somefilename.pop")
>>>    HttpContext.Current.Response.AddHeader("Content-Length",
>>> mystring.Length.ToString())
>>>    HttpContext.Current.Response.Write(mystring)
>>>    HttpContext.Current.Response.Flush()
>>>    HttpContext.Current.Response.End()
>>>
>>>    This works, but at current IE is giving me the option to either
>>> Open it or Save it.  I would like automatically open it, in the same
>>> way that Windows Media Player opens an mp3 automatically when clicked
>>> on a page.
>>>
>>>    Is this down to my ContentType?  I did try
>>> "application/octet-stream" but this kept telling IE that the file was
>>> a HTML document, when it isn't so it would only open it in the
>>> browser, or save it.
>>>
>>>    Many thanks in advance!
>>>
>>> Nick.
>>>
>>
>>