* Corrected boost version number for introduction of shutdown_service() (it was introduced as a private pure virtual method to boost::asio::io_service::service in version 1.47.  io_service::service is used as a base class for cgi/fcgi services...)
* Corrected boost version number for change from system_category (data) to system_category() method, which was a breaking change introduced in boost version 1.44
* Corrected <= to >= for shutdown_service() and system_category().
* Added boost version check for references to system_category to system_category() for win32_acceptor_service_impl.hpp and request_acceptor_service.hpp.
The binary 'and' bitwise operator being auto-evaluated as bool was not having the behavior the authors expected for parse_cookies and parse_form_only because these enumerations are not single bit values (i.e. 1,2,4,8,16) but a combination of single bit values.  As a result values were evaluating to true for the expression when not expected, resulting in exception behavior.  This has been fixed by explicitly comparing against the specified values after the bitwise 'and'.
* This is a work-around for a completely broken implementation. Specifically, thefunction call stack looks like:

    fcgi_request_service<Protocol>::handle_begin_request_header ->
    fcgi_request_service<Protocol>::parse_post_vars ->
    request_base::parse_post_vars ->
    form_parser::parse

Form parser explicitly states in documentation that valid form encodings are application/x-www-form-urlencoded, and multipart/form-data.  I am not familiar enough with HTML forms to know if this restriction is legitamite for html forms or not.  However, it is an invalid restriction for HTML POST in general, as long as the mime type is at least IANA registered (http://www.iana.org/assignments/media-types).

The code change is to allow POST of any (presumably IANA registered) mime type.  If the specific service implementation doesn't want to except it, then it can always return an error, but the library aught not prevent the server from accepting valid mime types, even if the server implementation hast to parse it manually.

(This problem was discovered when attempting to implement a RESTful service which accepts GET/POST for application/json)