- 15 5月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
This change introduces a strategy for expanding a URI template into a URI and makes it a property of the RestTemplate and AsyncRestTemplate so that they can be pre-configured with such a strategy. The DefaultUriTemplateHandler relies on UriComponentsBuilder internally and provides functionality equivalent to using the UriTemplate. A DefaultUriTemplateHandler can also be configured to parse the path of a URI template into path segments in order to allow expanding URI variables according to path segment encoding rules. Issue: SPR-12750
-
- 14 5月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12750
-
- 12 5月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
(cherry picked from commit 9e925aa8)
-
- 11 5月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 07 5月, 2015 1 次提交
-
-
由 Sebastien Deleuze 提交于
Issue: SPR-12983
-
- 05 5月, 2015 3 次提交
-
-
由 Sam Brannen 提交于
-
由 Rossen Stoyanchev 提交于
CorsConfiguration now provides methods to check and determine the allowed origin, method, and headers according to its own configuration. This simplifies significantly the work that needs to be done from DefaultCorsProcessor. However an alternative CorsProcessor can still access the raw CorsConfiguration and perform its own checks. Issue: SPR-12885
-
由 Sebastien Deleuze 提交于
This commit adds CORS related headers to HttpHeaders and update DefaultCorsProcessor implementation to use ServerHttpRequest and ServerHttpResponse instead of HttpServletRequest and HttpServletResponse. Usage of ServerHttpResponse allows to avoid using Servlet 3.0 specific methods in order keep CORS support Servlet 2.5 compliant. Issue: SPR-12885
-
- 04 5月, 2015 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12960
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12956
-
- 15 4月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-12910
-
- 14 4月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
The onFailure callback and future.get() occur in different threads so this change adds a latch to ensure we have both before asserting. Issue: SPR-12887
-
- 10 4月, 2015 1 次提交
-
-
由 Arjen Poutsma 提交于
RuntimeExceptions thrown from FutureAdapter.adapt() should be wrapped in an ExecutionException, not thrown as is. Issue: SPR-12887
-
- 04 4月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 02 4月, 2015 2 次提交
-
-
由 Sebastien Deleuze 提交于
This commit introduces support for CORS in Spring Framework. Cross-origin resource sharing (CORS) is a mechanism that allows many resources (e.g. fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated. It is defined by the CORS W3C recommandation (http://www.w3.org/TR/cors/). A new annotation @CrossOrigin allows to enable CORS support on Controller type or method level. By default all origins ("*") are allowed. @RestController public class SampleController { @CrossOrigin @RequestMapping("/foo") public String foo() { // ... } } Various @CrossOrigin attributes allow to customize the CORS configuration. @RestController public class SampleController { @CrossOrigin(origin = { "http://site1.com", "http://site2.com" }, allowedHeaders = { "header1", "header2" }, exposedHeaders = { "header1", "header2" }, method = RequestMethod.DELETE, maxAge = 123, allowCredentials = "true") @RequestMapping(value = "/foo", method = { RequestMethod.GET, RequestMethod.POST} ) public String foo() { // ... } } A CorsConfigurationSource interface can be implemented by HTTP request handlers that want to support CORS by providing a CorsConfiguration that will be detected at AbstractHandlerMapping level. See for example ResourceHttpRequestHandler that implements this interface. Global CORS configuration should be supported through ControllerAdvice (with type level @CrossOrigin annotated class or class implementing CorsConfigurationSource), or with XML namespace and JavaConfig configuration, but this is not implemented yet. Issue: SPR-9278
-
由 Sebastien Deleuze 提交于
This commit adds a filters property to MappingJacksonValue and also manages a special FilterProvider class name model key in order to be able to specify a customized FilterProvider for each handler method execution, and thus provides a more dynamic alternative to our existing JsonView support. A filters property is also now available in Jackson2ObjectMapperBuilder and Jackson2ObjectMapperFactoryBean in order to set easily a global FilterProvider. More details about @JsonFilter at http://wiki.fasterxml.com/JacksonFeatureJsonFilter. Issue: SPR-12586
-
- 01 4月, 2015 4 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Arjen Poutsma 提交于
Before this commit, Netty4ClientHttpRequest ignored query parameters (?foo=bar). This commit fixes that. Issue: SPR-12779
-
由 Rossen Stoyanchev 提交于
-
由 Arjen Poutsma 提交于
This commit introduces support for "Path Segment URI Variable expansion", see https://tools.ietf.org/html/rfc6570#section-3.2.6. In practice, this means that URI template variables prefixed with a '/' are treated like path segments and - as such - will encode any '/' found. For example: {/foo} expanded with "bar/baz" with result in "bar%2F". Issue: SPR-12750
-
- 24 3月, 2015 4 次提交
-
-
由 Rossen Stoyanchev 提交于
This reverts commit a57d4282 after the realization of a weaknesses with the proposed approach. For example if a path segment contains both a /-prefixed and a regular URI variable, there is no way to split that into a sequence of path and path segments. The solution will have to be on the side of UriComponents at the time of encoding.
-
由 Brian Clozel 提交于
Prior to this commit, Cache-Control HTTP headers could be set using a WebContentInterceptor and configured cache mappings. This commit adds support for cache-related HTTP headers at the controller method level, by returning a ResponseEntity instance: ResponseEntity.status(HttpStatus.OK) .cacheControl(CacheControl.maxAge(1, TimeUnit.HOURS).cachePublic()) .eTag("deadb33f8badf00d") .body(entity); Also, this change now automatically checks the "ETag" and "Last-Modified" headers in ResponseEntity, in order to respond HTTP "304 - Not Modified" if necessary. Issue: SPR-8550
-
由 Brian Clozel 提交于
This commit improves HTTP caching defaults and flexibility in Spring MVC. 1) Better default caching headers The `WebContentGenerator` abstract class has been updated with better HTTP defaults for HTTP caching, in line with current browsers and proxies implementation (wide support of HTTP1.1, etc); depending on the `setCacheSeconds` value: * sends "Cache-Control: max-age=xxx" for caching responses and do not send a "must-revalidate" value by default. * sends "Cache-Control: no-store" or "Cache-Control: no-cache" in order to prevent caching Other methods used to set specific header such as `setUseExpiresHeader` or `setAlwaysMustRevalidate` are now deprecated in favor of `setCacheControl` for better flexibility. Using one of the deprecated methods re-enables previous HTTP caching behavior. This change is applied in many Handlers, since `WebContentGenerator` is extended by `AbstractController`, `WebContentInterceptor`, `ResourceHttpRequestHandler` and others. 2) New CacheControl builder class This new class brings more flexibility and allows developers to set custom HTTP caching headers. Several strategies are provided: * `CacheControl.maxAge(int)` for caching responses with a "Cache-Control: max-age=xxx" header * `CacheControl.noStore()` prevents responses from being cached with a "Cache-Control: no-store" header * `CacheControl.noCache()` forces caches to revalidate the cached response before reusing it, with a "Cache-Control: no-store" header. From that point, it is possible to chain method calls to craft a custom CacheControl instance: ``` CacheControl cc = CacheControl.maxAge(1, TimeUnit.HOURS) .cachePublic().noTransform(); ``` 3) Configuring HTTP caching in Resource Handlers On top of the existing ways of configuring caching mechanisms, it is now possible to use a custom `CacheControl` to serve resources: ``` @Configuration public class MyWebConfig extends WebMvcConfigurerAdapter { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { CacheControl cc = CacheControl.maxAge(1, TimeUnit.HOURS); registry.addResourceHandler("/resources/**) .addResourceLocations("classpath:/resources/") .setCacheControl(cc); } } ``` or ``` <mvc:resources mapping="/resources/**" location="classpath:/resources/"> <mvc:cachecontrol max-age="3600" cache-public="true"/> </mvc:resources> ``` Issue: SPR-2779, SPR-6834, SPR-7129, SPR-9543, SPR-10464
-
由 Markus Malkusch 提交于
This change improves the following use cases with `WebRequest.checkNotModified(String etag)` and `WebRequest.checkNotModified(long lastModifiedTimeStamp)`: 1) Allow weak comparisons for ETags Per rfc7232 section-2.3, ETags can be strong or weak; this change allows comparing weak forms `W/"etagvalue"` but does not make a difference between strong and weak comparisons. 2) Allow multiple ETags in client requests HTTP clients can send multiple ETags values in a single header such as: `If-None-Match: "firstvalue", "secondvalue"` This change makes sure each value is compared to the one provided by the application side. 3) Extended support for ETag values This change adds padding `"` to the ETag value provided by the application, if not already done: `etagvalue` => `"etagvalue"` It also supports wildcard values `*` that can be sent by HTTP clients. 4) Sending validation headers for 304 responses As defined in https://tools.ietf.org/html/rfc7232#section-4.1 `304 Not Modified` reponses must generate `Etag` and `Last-Modified` HTTP headers, as they would have for a `200 OK` response. 5) Providing a new method to validate both Etag & Last-Modified Also, this change adds a new method `WebRequest.checkNotModified(String etag, long lastModifiedTimeStamp)` in order to support validation of both `If-None-Match` and `Last-Modified` headers sent by HTTP clients, if both values are supported by the application code. Even though this approach is recommended by the HTTP rfc (setting both Etag and Last-Modified headers in the response), this requires more application logic and may not apply to all resources produced by the application. Issue: SPR-11324
-
- 21 3月, 2015 6 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12677
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12750
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10805
-
由 Arjen Poutsma 提交于
This commit introduces support for HTTP byte ranges in the ResourceHttpRequestHandler. This support consists of a number of changes: - Parsing of HTTP Range headers in HttpHeaders, using a new HttpRange class and inner ByteRange/SuffixByteRange subclasses. - MIME boundary generation moved from FormHttpMessageConverter to MimeTypeUtils. - writePartialContent() method introduced in ResourceHttpRequestHandler, handling the byte range logic - Additional partial content tests added to ResourceHttpRequestHandlerTests. Issue: SPR-10805
-
由 Rossen Stoyanchev 提交于
After this change UriComponentsBuilder#uriComponents method no longer no longer copies from the given UriComponents but rather lets the UriComponents instance copy itself to the UriComponentsBuilder. This avoids the need for instanceof checks and also makes it possible to distinguish between path and path segments, which otherwise is internal knowledge of UriComponentsBuilder. Issue: SPR-12742
-
- 14 3月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12816
-
- 13 3月, 2015 3 次提交
-
-
由 Brian Clozel 提交于
Prior to this commit, the ContentCachingRequestWrapper would immediately consume the wrapped request's InputStream when asked for the cached content; that caused several issues: * the request body was read in memory even if it wasn't yet consumed by the application, leading to inefficiencies. * when requesting the InputStream, an empty InputStream was returned since the original was already read. This case only happened for form POSTs requests. This commit makes sure that the wrapper does not alter the request expected behavior: * when getting the inputstream, it is wrapped in order to cache its content * when getting request parameters, the request body is cached and its inputstream is consumed, as expected Issue: SPR-12810
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12813
-
由 Rossen Stoyanchev 提交于
-
- 10 3月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-12792
-
- 08 3月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 06 3月, 2015 3 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Arjen Poutsma 提交于
All HttpMessageConverters should support StreamingHttpOutputMessage. Specifically, the BufferedImageHttpMessageConverter and FormHttpMessageConverter should do so. Issue: SPR-12715
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12771
-
- 03 3月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Latest dependency updates (HttpClient 4.4, TestNG 6.8.21, SnakeYAML 1.15, FreeMarker 2.3.22, JRuby 1.7.19, JAMon 2.81, JiBX 1.2.6, XMLUnit 1.6, JsonPath 1.2)
-