Writing a file in Response

[nak]

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.

 

[nak]

Just to add, I'm using IE8 and the "always ask before opening this type of
file" checkbox is not visible.

 

[Mike]

You need to register the MIME type and extension on the PC.

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 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,.

 

[nak]

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]

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.

--

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.

 

[nak]

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.

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.

--

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]

Nick, don't recall you mentioning if you tried your code with other
browsers, like IE6/7, FireFox, OPERA, K-Meleon, Safari for Windows.

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?

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.

--

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.

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.

--

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.

 

[nak]

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.

 

[nak]

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]

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.

--

 

[Cor Ligthert[MVP]]

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]

I've got it now, the routine to serve a .torrent which can be run
automatically should like like the following,

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()

So no attachment header was necessary and the addition of an Accept-Ranges
header was required.

All sorted, thanks a million for your help.

Nick.

 

[nak]

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!

 

[Mike]

Cool Beans! Glad u got it worked out!

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!

 

[nak]

Cool Beans! Glad u got it worked out!

Cheers mate, yeah it was a bit of a reliefe! lol! As before I got this
working we had the client side application being invoked from an URL, but as
it was being invoked from a https source it would complain of leaving the
secure zone. Really badly implemented if you ask me because how on earth
could MS say that a custom URL isn't secure? Pah, you kinda wonder what the
point in getting your apps digitally signed is to be totally honest, it
seems pointless.

Nick.

 

[Mike]

Cheers mate, yeah it was a bit of a reliefe! lol! As before I got this
working we had the client side application being invoked from an URL,
but as it was being invoked from a https source it would complain of
leaving the secure zone. Really badly implemented if you ask me because
how on earth could MS say that a custom URL isn't secure? Pah, you
kinda wonder what the point in getting your apps digitally signed is to
be totally honest, it seems pointless.

+1.

The reasons are generally because of code (like javascript) and url
injection.

If you try to do this via AJAX, you will have other security rules and
MS has rules that overrides the "standard security" - which is

"THOU SHALL NOT DO CROSS DOMAINS VIA XHR (AJAX)"

IE will display a Security Box asking the user if the AJAX request is
ok (I think its ALLOW/ASK/DENY option somewhere) others will simply
not allow it and will throw an exception.

The current approaches to get around this:

- a client-side browser object; ActiveX, Java, Flash, SilverLight,
etc.

- JSONP, JavaScript JSON + Server Side "Proxy" Engine

Both are used/mixed, the latter is gaining since you don't need to
install anything on the user side. You see this a lot in Cross Domain
Logins.

So overall, it makes portable code for different browsers more
difficult. Good or bad, the WEB 2.0 "market place" requires it (Ads,
tracking, Web Services, etc), so even the new browsers are relaxing
the security and enforcing Javascipt. Some browsers, which is really
unfortunately, have began to REMOVE the user options to turn some of
this off, like Javascript. Chrome for example, doesn't even provide
users the option to turn off Javascript. For me, its an ethical
engineering dilemma - as a User I don't like the security direction we
are at, as a engineer I don't like to support such any idea opens door
and promotes user vulnerabilities in the name of integration and
automation. Yet, if you don't, you fall behind. :-( Now that google
has introduced Chrome with these less security ideas, others browsers
have began to follow. All browsers will one day not give the user the
option to turn off javascript.

Anyway I digress

--