I am using aspnetboilerplate version 5.13.0. I want response cache but it didn't work no matter what i tried. Response Header has always cache-control: no-cache, no-store.
I tried the following;
I just added the response cache attribute.
Response Cache middleware and cache profile.
I defined DefaultResponseCacheAttributeForControllers in WebCoreModule PreInitialize
Offical Documentation;
Abp provides a convenient way for you to configure the default Cache-Control header for all ApplicationService and Controller via IAbpAspNetCoreConfiguration
DefaultResponseCacheAttributeForAppServices: Used if Controller class does not define Microsoft.AspNetCore.Mvc.ResponseCacheAttribute
DefaultResponseCacheAttributeForControllers: Used if ApplicationService class does not define Microsoft.AspNetCore.Mvc.ResponseCacheAttribute
Note: Cache-Control is not configured by default. You may configure for all ApplicationService and Controller then use Microsoft.AspNetCore.Mvc.ResponseCacheAttribute at method/action level to override it.
But it is a bit difficult for me to understand. Does anyone have a code sample?
Related
I assume that Spring Dispatcher automatically include Allow header when a particular URL is requested via OPTIONS method. Is there any way we can override the Allow header which Spring sets Out of box? If yes, what would be the best way?
I meant to say Dispatcher servlet.
FYI. Answer to this question is HttpServlet's doOptions method identifies the methods supported by DispatcherServlet and sets the OPTIONS header. So what we can do is to add a filter to explicitly override the OPTIONS header
I'm using Spring Data REST to build a RESTful API. Until now my HTML GUI for this RESTful service was served from the same Tomcat and I had no problems wit Cross Origin requests.
Now I want to serve the static files from a different server. This means the API is on another domain/port. Browsers will send the OPTIONS request to get the Access-Control headers from the server. Unfortunately Spring Data REST does not handle those OPTIONS requests and even returns a HTTP 500.
I tried creating a custom controller that handles all OPTIONS requests
#Controller
#RequestMapping(value = "/**", method = RequestMethod.OPTIONS)
public class OptionsController {
#RequestMapping
public ResponseEntity options() {
return new ResponseEntity<Void>(HttpStatus.OK);
}
}
Which worked for OPTIONS, but then all other requests (like GET) ceased to work.
OPTIONS requests are switched on via the dispatchOptionsRequest dispatcher servlet parameter.
tl;dr: currently Spring Data REST does not answer OPTIONS requests at all.
It might be worth opening a ticket in our JIRA.
Browsers will send the OPTIONS request to get the Access-Control headers from the server.
Is that specified somewhere? If so, it would be cool if the ticket description included a link to that spec.
A few comments regarding your approach for a workaround:
#RequestMapping on the controller method overrides the method attribute and expectedly now matches all HTTP methods, which is why you see all requests intercepted. So you need to define OPTIONS as HTTP method there, too (or maybe instead of in the class mapping).
You're not returning any Allow header which is the whole purpose of OPTIONS in the first place.
I wonder if the approach in general makes sense as it'll be hard to reason about the supported HTTP methods in general.
Just set the parameter dispatchOptionsRequest to true into the dispatcher to process the Options method calls, into the implementation of the WebApplicationInitializer.
ServletRegistration.Dynamic dispatcher = container.addServlet("dispatcher", new DispatcherServlet(applicationContext));
dispatcher.setInitParameter("dispatchOptionsRequest", "true");
dispatcher.setLoadOnStartup(1);
dispatcher.addMapping("/*");
I am currently developing an OData service using Web Api 2 and EF6 with a Code First Approach. My controllers inherit from the normal ApiController Base.
I have decorated my action methods with the Queryable attribute and have also enabled Query Support in the WebApiConfig file. Through my CORS policy, I have specified the DataServiceVersion and MaxDataServiceVersion as part of my Accept and Exposed Headers.
Strangely, my odata endpoint seems to not return the DataServiceVersion as part of the response header but, if my controllers inherit from the ODataController base I am able to see it in the response.
Is there a way to enable this header while using ApiController as the base.
This header is needed as datajs requires it on the client side.
First to answer your question:
Yes, you can expose the DataServiceVersion http header yourself. It's custom code though, not a setting on an existing component.
Add a "Filter" to your global http configuration. A filter is a class derived from "System.Web.Http.Filters.ActionFilterAttribute".
for example;
internal class DataServiceVersionHeaderFilterWebAPI : System.Web.Http.Filters.ActionFilterAttribute
{
public override void OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
{
actionExecutedContext.Response.Content.Headers.Add("DataServiceVersion", "3.0");
actionExecutedContext.Response.Content.Headers.Add("Access-Control-Expose-Headers", "DataServiceVersion");
}
}
Then configure this filter to be used (in application start of global.asax)
GlobalConfiguration.Configuration.Filters.Add( new DataServiceVersionHeaderFilterWebAPI() );
This will allow your cross domain OData query from a security perspective. There is however another issue with this;
OData is a specification larger than just the request URI's & HTTP headers. It also specifies how to exchange model information and the actual data exchange is a predefined object structure. Simple, but still a predefined structure.
object.d = service returned content
You will have to implement all those pieces of the specification ($filter,$metadata,$top, return formats, etc) yourself.
Some food for thought.
I know this question is very similar to this one, but I feel its different and specific enough to warrant its own question here.
I've just inherited a Java web app project from a sole developer who left no documentation behind. Its a Spring MVC app with a basic package structure as follows:
com.ourOrg.app.controllers
ImageController
ProgramController
UserController
com.ourOrg.app.otherPackages
Each Controller class is just a POJO annotated with #Controller and #RequestMapping("/blah"). For instance:
#Controller
#RequestMapping("/images")
public class ImageController() {
#RequestMapping(value="/saveImage", method = RequestMethod.POST)
#ResponseBody
public ResponseEntity<String> saveImage(#RequestParam(value="imageData", required=true) String imageXML, HttpServletRequest request){
// This method gets executed whenever the:
// http://ourSite.com/images/saveImage
// URL is hit
}
}
I have been asked to add the following HTTP headers to the Spring config so that we disable browser caching:
Pragma: no-cache
Cache-Control: no-cache
Expires: -1
The article I linked to above makes it sound like our controllers should be extending this WebContentGenerator class. Unfortunately, there are dozens of controllers with an enormous number of methods, so refactoring each one to extend or inherit some base type is not really a viable option (unless its the only option!).
I've also seen articles that make it sound like you have to configure Spring to use AOP interceptors that modify your response headers, but now I'm really getting into unfamiliar territory.
Given our setup and implementation of Spring MVC, whats the easiest way for me to add these three simple headers to every response sent back by the server (regardless of which controller or method is executed)?
Thanks in advance!
Hoping you are using Spring 3, you can look at an interceptor, then you won't have to modify all of your controllers (since you said you had many). It looks like they may already have one implemented that you can just use. Check out Bozho's answer to this question how to set header no cache in spring mvc 3 by annotation
I realize this is an old post but maybe this will help somebody. I am using Spring for this example.
The main thing is use the annotation for parameters:
#Controller
public class HelloController {
#RequestMapping(value = "/hello.htm")
public String hello(#RequestHeader(value="User-Agent") String userAgent)
//..
}
}
WebContentInterceptor is nice, but I can't find how to make it add the "private" directive to the CacheControl HTTP header.
I either need to subclass it, or use response.setHeader in my controllers.
Is there any other convenient way to do this?
Preferably something annotation based :-)
Try https://github.com/foo4u/spring-mvc-cache-control. And it's annotation based :D.
It seems that Spring is taking into account adding this in a future version: https://jira.springsource.org/browse/SPR-7129.
Meantime, it seems that it's included in v4.2.