Serving images via ApplicationOctetStreamCodec

[Heath]

When using ApplicationOctetStreamCodec to stream byte arrays from a
database, how do I set the mime type and content disposition (file
name and whether or not it's served as an attachment or inline) on-the-
fly from within the handler method? My guess is I'm using the wrong
codec for this. Here's my configuration code:

ResourceSpace.Has.ResourcesOfType<System.IO.Stream>()
.AtUri(_uriRoot + "ServeImage/{imageID}").Named("si")
.HandledBy<ImageHandler>()
.TranscodedBy<ApplicationOctetStreamCodec>(null);

And the handler code:

[HttpOperation(HttpMethod.GET, ForUriName = "si")]
public OperationResult ServeImage(int imageID) {

byte[] imageFile;
...
return new OperationResult.OK { ResponseResource = imageFile };
}

Thanks!

[Sebastien Lambla]

Which version are we talking about?

The ApplicationOctetStreamCodec is already registered for IFile and

In the latest trunk, you can simply do this:

ResourceSpace.Has.ResourcesOfType<DownloadableImage>()
.AtUri("/ServeImage/{imageId}")
.HandledBy<ImageHandler>();

public class DownloadableImage : InMemoryDownloadableFile
{
public DownloadableImage(byte[] content){
OpenStream().Write(content, 0, content.Length);
}
}
public class ImageHandler
{
public OperationResult GetImage(int imageID) {

byte[] imageFile;
...
return new OperationResult.OK { ResponseResource = new
DownloadableImage(imageFile) };
}
}

Note that there's a bunch of other properties that let you set the filename
and the media type of the binary stream.

Seb

[Heath]

Thank you Seb!! This works for the most part. I do have a couple of
notes for you.

The InMemoryDownloadableFile class ignores the setting for Options and
always treats the disposition as attachment
(DownloadableFileOptions.Save). I verified this in Fiddler. However
I found that if I used the InMemoryFile class instead it served the
file inline which in this case is what I needed. Both
InMemoryDownloadableFile and InMemoryFile seem to ignore the
ContentType setting and thus always serve the files back as
application/octet-stream, again verified by Fiddler. Even if I set it
to one of the predefined media types (e.g. MediaType.TextPlain) I get
the same behavior. IE doesn't care and serves the images just fine
but FF throws up a download dialog even though the disposition is
inline.

btw I'm using OpenRasta 2.0.3079.352 and it ROCKS. Keep up the great
work!

[Sebastien Lambla]

Thanks :)

> The InMemoryDownloadableFile class ignores the setting for Options and
> always treats the disposition as attachment
> (DownloadableFileOptions.Save). I verified this in Fiddler. However
> I found that if I used the InMemoryFile class instead it served the
> file inline which in this case is what I needed.

The idea of the DownloadableFileOptions is to add support for the special
http headers IE recognizes for enabling or disabling the Open and Save
buttons in the download box. It's not implemented yet :)

IDownloadableFile always results in an attachment, and IFile always an
inline.

> Both
> InMemoryDownloadableFile and InMemoryFile seem to ignore the
> ContentType setting and thus always serve the files back as
> application/octet-stream, again verified by Fiddler.

I'll add a regression test to openbastard to test that behavior. Strange
thing is, the app/octet-stream is normally only used as a default. Which
host are you using?

Thinking of it, there should probably be a check in the codec that when you
set the mediatype, that mediatype is compatible with the Accept: header sent
by the client. Otherwise it could make for weird results.

> Even if I set it
> to one of the predefined media types (e.g. MediaType.TextPlain) I get
> the same behavior. IE doesn't care and serves the images just fine
> but FF throws up a download dialog even though the disposition is
> inline.

IE is doing sniffing there, firefox just executes teh default action for the
Content-Type: application/octet-stream

Will try and get a fix tonight

Seb

-----Original Message-----
From: open...@googlegroups.com [mailto:open...@googlegroups.com] On
Behalf Of Heath
Sent: 10 September 2009 14:55
To: OpenRasta
Subject: [openrasta] Re: Serving images via ApplicationOctetStreamCodec

Thank you Seb!! This works for the most part. I do have a couple of
notes for you.

btw I'm using OpenRasta 2.0.3079.352 and it ROCKS. Keep up the great

[Heath]

Wow I really appreciate you addressing this so quickly! By host do
you mean server specs? I have the OR framework running in a subapp of
my web in IIS 6.0, .NET 3.5 Windows 2003 Server, testing the method
uris thru IE 7 and FF 3.5.

[Heath]

Using the latest trunk version 2.0.3081.354 I'm still having the
"application/octet-stream" issue in which I explicitly set the mime
type and serve an InMemoryFile. When inspecting the InMemoryFile
object right before returning it as the ResponseResource in an
OperationResult.OK it shows the correct ContentType. I've even tried
just as a temporary hack to set it through the aspnet native Response
object but of course the ContentType is being set to application/octet-
stream somewhere down the pipe.

Here's a guess as to what might be causing this. In the
WriteFileWithFilename method of the ApplicationOctetStreamCodec class
the following line sets the IHttpEntity's ContentType:

if (response.ContentType == null)
response.ContentType = file.ContentType ??
MediaType.ApplicationOctetStream;

Is it possible the IHttpEntity's ContentType isn't null at this point
and therefore the response's ContentType fails to be set to the
file's? Or if it's not null file.ContentType is null for some reason?

Thanks,
Heath

[Heath]

FYI this is now working in the latest trunk! OpenRasta-2.0.3092.367

On Sep 14, 10:24 am, Heath <hho...@gmail.com> wrote:
> Using the latest trunk version 2.0.3081.354 I'm still having the
> "application/octet-stream" issue in which I explicitly set the mime
> type and serve an InMemoryFile.  When inspecting the InMemoryFile
> object right before returning it as the ResponseResource in an

> OperationResult.OK it shows the correctContentType.  I've even tried

> just as a temporary hack to set it through the aspnet native Response

> object but of course theContentTypeis being set to application/octet-

> stream somewhere down the pipe.
>
> Here's a guess as to what might be causing this.  In the
> WriteFileWithFilename method of the ApplicationOctetStreamCodec class
> the following line sets the IHttpEntity'sContentType:
>
> if (response.ContentType== null)
>         response.ContentType= file.ContentType??
> MediaType.ApplicationOctetStream;
>

> Is it possible the IHttpEntity'sContentTypeisn't null at this point
> and therefore the response'sContentTypefails to be set to the
> file's?  Or if it's not null file.ContentTypeis null for some reason?

>
> Thanks,
> Heath
>
> On Sep 10, 2:04 pm, Heath <hho...@gmail.com> wrote:
>
> > Wow I really appreciate you addressing this so quickly!  By host do
> > you mean server specs?  I have the OR framework running in a subapp of
> > my web in IIS 6.0, .NET 3.5 Windows 2003 Server, testing the method
> > uris thru IE 7 and FF 3.5.
>
> > On Sep 10, 11:09 am, "Sebastien Lambla" <s...@serialseb.com> wrote:
>
> > > Thanks :)
>
> > > > The InMemoryDownloadableFile class ignores the setting for Options and
> > > > always treats the disposition as attachment
> > > > (DownloadableFileOptions.Save).  I verified this in Fiddler.  However
> > > > I found that if I used the InMemoryFile class instead it served the
> > > > file inline which in this case is what I needed.  
>
> > > The idea of the DownloadableFileOptions is to add support for the special
> > > http headers IE recognizes for enabling or disabling the Open and Save
> > > buttons in the download box. It's not implemented yet :)
>
> > > IDownloadableFile always results in an attachment, and IFile always an
> > > inline.
>
> > > > Both
> > > > InMemoryDownloadableFile and InMemoryFile seem to ignore the

> > > >ContentTypesetting and thus always serve the files back as