The AbstractHttpMessageConverter was using the requested Content-Type
rather than the actual response Content-Type to determine the length
of the content. This can lead to a problem when a controller returns
a ResponseEntity with a Content-Type header that ignores (overrides)
the requested Content-Type. The fix ensures that actual response
Content-Type is the one used both to write to the response and to
determine the length of the content.
The UriComponentsBuilder instance passed into the method is initialized
with current request information including host, scheme, port, context
path, and the servlet mapping's literal part.
Also added shortcut methods to buildAndExpand in UriComponentsBuilder.
The Content-Type header and the contentType field in HttpServletRequest/Response
are now always in sync. When a header is added the contentType field is updated
as well and vice versa.
Similarly when the Content-Type header or the contentType field includes a charset
field, the character encoding is updated and vice versa.
Since dynamic attributes were allowed in Spring 3, it raised the
possibility to specify a type attribute on a number of the form tags.
Where it makes sense (see below) that attribute is now rejected
and reversely where it makes sense it is accepted.
InputTag allows types other than "text" but rejects type="radio" or
type="checkbox" since there is a good reason for those to be used
only in conjunction with the appropriate form library tags.
Other HTML input tags such as PasswordTag, HiddenInputTag,
Checkbox(es)Tag and RadioBox(es)Tag check the dynamic attributes
and reject them if they contain a type attribute since.
Certain external javadoc links were broken or out of date, namely
Hibernate, Java SE and EE 6, Quartz, and Apache Pluto. All resolve
properly now.
Issue: SPR-8720
