Content-Type / Cache-Control headers in exposed REST services

Content-Type / Cache-Control headers in exposed REST services

  

Hi.

I am trying to expose a REST service for downloading a video. Since videos take very long to download, I cannot use a web screen with a download node, because it would lock the user session, and other requests would be queued and would need to wait until the whole video was downloaded. REST services do not lock session, so... problem solved.


Except, I cannot override the Content-Type and Cache-Control headers. Responses always have Content-Type: application/octet-stream and Cache-Control: no-cache. I tried adding these headers as outputs to the REST, but they don't seem to do anything.

I was able to override Content-Type by using HTTPRequestHandler's AddHeader method. But Cache-Control still evaded this technique.


Does anyone know if those headers can be overriden at all? Or maybe I should be following another approach? IMHO this should be fairly simple, just like adding the headers on the exposed REST and filling them out.

Thanks for any help.

Hi Leonardo Fernandes, 

You can override the Cache-Control  the same way using the HTTPRequestHandler.
See image below.

"Cache-Control"
"max-age=2592000"

Regards,

Robin

Hello Robin.

I have tried that, but sadly it doesn't work. So I'm looking for another alternative.


Robin Kouwen wrote:

Hi Leonardo Fernandes, 

You can override the Cache-Control  the same way using the HTTPRequestHandler.
See image below.

"Cache-Control"
"max-age=2592000"

Regards,

Robin



Hi Leonardo

Unfortunately there is a platform limitation in setting cache control headers (Cache-Control, Expires) in Expose REST, namely in the .NET stack.

Is the Cache-Control header necessary for your scenario?

Cheers

Hi João.

Yes, I need to set the cache-control. I'm developing a service for downloading videos, and it would be good for the browser to cache the videos, since they are big and immutable.

Is it possible to override the Cache-Control in an extension, somehow?

Thanks.

Hi Leonardo

Unfortunately there isn't a way to do this, even via extensibility, as there currently is no available way to access the framework response object. We will review this limitation on a future version.

Not even by using HttpContext.Current.Response?

Hi Leonardo, 


The thing is that the WebApi (the framework that we are using for REST in .NET) forces the default cache headers when they were not explicitly set in their objects, overriding any of them that you might set into the Current.Response. Since those objects can't be accessed via extensibility, that makes it a limitation on the current version of the platform.


(humm just noticed that on Robin post there is an extra space in the string ...hope its not an wierd hack to make it work)


For the Content-Type that you can set and we respect the value. In some versions it might not work in some places, either inside the methot or inside the OnResponse (don't remember exacty which didn't work), but it always worked in one of them. 


Regards,

João Rosado

Thanks João, that was valuable information!

I'll check to see if there's some way around it, anyway.