- 20 7月, 2015 2 次提交
-
-
由 Sebastien Deleuze 提交于
-
由 Sebastien Deleuze 提交于
Issue: SPR-13192
-
- 17 7月, 2015 2 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
AllEncompassingFormHttpMessageConverter registers MappingJackson2XmlHttpMessageConverter and GsonHttpMessageConverter (for consistency with RestTemplate and WebMvcConfigurationSupport) Issue: SPR-13240
-
- 15 7月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 14 7月, 2015 2 次提交
-
-
由 Stephane Nicoll 提交于
When using an Apache Http components based infrastructure, a null header value is handled as the empty string. The exact same infrastructure using HttpURLConnection generates a header with no colon. This is actually not proper HTTP and some components fail to read such request. We now make sure to call HttpURLConnection#addRequestProperty with the empty String for a null header value. Issue: SPR-13225
-
由 Juergen Hoeller 提交于
Issue: SPR-13191
-
- 13 7月, 2015 2 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13212
-
由 Sebastien Deleuze 提交于
Browsers like Chrome or Safari include an Origin header for same-origin POST/PUT/DELETE requests, not only for cross-origin requests. Before this commit, these same-origin requests would have been detected as potential cross-origin requests, and rejected if the same-origin domain is not part of the configured allowedOrigins. This commit avoid to reject same-origin requests by reusing the logic introduced in Spring 4.1 for detecting reliably Websocket/SockJS same-origin requests with the WebUtils.isValidOrigin() method. This logic has been extracted in a new WebUtils.isSameOrigin() method. Issue: SPR-13206
-
- 10 7月, 2015 2 次提交
-
-
由 Sebastien Deleuze 提交于
-
由 Sebastien Deleuze 提交于
This commit introduces the following changes: - The new CorsConfigurationMapping class allows to share the mapped CorsConfiguration logic between AbstractHandlerMapping and CorsFilter - In AbstractHandlerMapping, the Map<String, CorsConfiguration> corsConfiguration property has been renamed to corsConfigurations - CorsFilter allows to process CORS requests at filter level, using any CorsConfigurationSource implementation (for example CorsConfigurationMapping) Issue: SPR-13192
-
- 07 7月, 2015 4 次提交
-
-
由 Sebastien Deleuze 提交于
-
由 Sebastien Deleuze 提交于
Issue: SPR-13193
-
由 Rossen Stoyanchev 提交于
When using Appache Commons FileUpload, multi parts with binary data (i.e. that are not actual files) are saved and then accessed as String request parameters. Before this change however the RequestPartServletServerHttpRequest used a fixed encoding (UTF-8) while the parsing code in CommonsFileUploadSupport/Resolver used the encoding from the content-type header, or the request, or the FileUpload component. This change does a best effort to determine the encoding of the request parameter using a similar algorithm as the parsing side that should work the same unless the encoding comes from the FileUpload component which is not accessible. Issue: SPR-13096
-
由 Sam Brannen 提交于
-
- 06 7月, 2015 2 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13200
-
由 Juergen Hoeller 提交于
Issue: SPR-11861
-
- 04 7月, 2015 1 次提交
-
-
由 Brian Clozel 提交于
Issue: SPR-13194
-
- 01 7月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 30 6月, 2015 4 次提交
-
-
由 Juergen Hoeller 提交于
XML parsing tests pass on non-English locales now, plus a revised exception message and some minor polishing Issue: SPR-13136 (cherry picked from commit 38b8262e)
-
由 Rossen Stoyanchev 提交于
Issue: SPR-13136
-
由 Juergen Hoeller 提交于
Issue: SPR-13004
-
由 Juergen Hoeller 提交于
This split avoids a package tangle (between core and core.annotation) and also allows for selective use of raw annotation exposure versus synthesized annotations, with the latter primarily applicable to web and message handler processing at this point. Issue: SPR-13153
-
- 29 6月, 2015 1 次提交
-
-
由 Brian Clozel 提交于
Prior to this commit, `HttpEntityMethodProcessor` would rely on `ServletWebRequest` to process conditional requests and with incoming `"If-Modified-Since"` / `"If-None-Match"` request headers. This approach is problematic since in that class: * response is wrapped in a `ServletServerHttpResponse` * this wrapped response does not write response headers right away * `ServletWebRequest.checkNotModified` methods can't apply their logic with incomplete response headers This solution adds some minimal code duplication and applies the conditional request logic within the Processor. A possible alternative would be to improve the `ServletServerHttpResponse$ServletResponseHttpHeaders` implementation with write methods - but this solution would only work for Servlet 3.x applications. Issue: SPR-13090
-
- 27 6月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-12938
-
- 26 6月, 2015 3 次提交
-
-
由 Sam Brannen 提交于
-
由 Sebastien Deleuze 提交于
Issue: SPR-12501
-
由 Sebastien Deleuze 提交于
Previous Jackson versions do not serialize polymorphic collections correctly when the type is specified. Issue: SPR-12811
-
- 25 6月, 2015 1 次提交
-
-
由 Sebastien Deleuze 提交于
This commit introduces the following changes: - In AbstractMessageConverterMethodProcessor, the type aware variant of canWrite() is now called when the converter implements GenericHttpMessageConverter. - The Javadoc has been updated in GenericHttpMessageConverter to make it clear that the type aware canRead() and canWrite() methods should perform the same checks than non type aware ones. - AbstractGenericHttpMessageConverter now implements default type aware canRead() and canWrite() methods than just call the non type aware variants. Due to this, if subclasses just override the non type aware variants, they still have the right behavior. Issue: SPR-13161
-
- 22 6月, 2015 1 次提交
-
-
由 Sebastien Deleuze 提交于
This commit adds canWrite() and write() methods to the GenericHttpMessageConverter interface. These are type aware variants of the methods available in HttpMessageConverter, in order to keep parametrized type information when serializing objects. AbstractMessageConverterMethodProcessor now calls those type aware methods when the message converter implements GenericHttpMessageConverter. AbstractJackson2HttpMessageConverter and GsonHttpMessageConverter uses these new methods to make @ResponseBody method return type available for type resolution instead of just letting the JSON serializer trying to guess the type to use from the object to serialize. Issue: SPR-12811
-
- 20 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
- Simplified "check" algorithms in CorsConfiguration - Improved robustness of setter methods in CorsConfiguration in order to avoid attempts to modify immutable lists - Improved CORS documentation and fixed typo - Introduced constants in CorsConfiguration - Removed auto-boxing in CorsRegistration
-
- 19 6月, 2015 1 次提交
-
-
由 Sebastien Deleuze 提交于
-
- 18 6月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11193
-
- 16 6月, 2015 5 次提交
-
-
由 Rossen Stoyanchev 提交于
Before this change HandlerMethodReturnValueHandler's were invoked in a specific order (type-based, annotation-based, custom). However handlers that deal with asynchronous return value handling need to always be considered first. This affects custom handlers in particular since they are normally ordered last. This change introduces an AsyncHandlerMethodReturnValueHandler sub-interface with a single method to determine if the return value is asynchronous and if it is to look for a matching handler only among those that are of type AsyncHandlerMethodReturnValueHandler. Issue: SPR-13083
-
由 Sebastien Deleuze 提交于
Issue: SPR-13078
-
由 Juergen Hoeller 提交于
-
由 Rossen Stoyanchev 提交于
Before this change a missing path variable value resulted in a 400 error where in fact the error is due to a mismatch between the declared @PathVariable and the URI template, i.e. a 500 error. This change introduced a MissingPathVariableException as a sub-class of ServletRequestBindingException (the exception previously thrown) and results in a response status code of 500 by default. Issue: SPR-13121
-
由 Stephane Nicoll 提交于
This is a rework of 71783c5d for SPR-12540 for the async extension that was not merging the internal RequestConfig as it should. Issue: SPR-13125
-
- 15 6月, 2015 1 次提交
-
-
由 Stephane Nicoll 提交于
Issue: SPR-13129
-
- 13 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
- origin --> origins - method --> methods - constants are now actually constant (i.e., static final)
-