HTMLForm::readMultipart does not contact its PartHandler if the Content-Disposition header does not contain a "filename" parameter. RTF 2388 states that this parameter is optional, only "name" is required. If PartHandler would have a method, e.g. "virtual bool shouldHandlePart(const MessageHandler&)", then the PartHandler could decide whether to handle the part itself. This would allow for handling of other "Content-*" headers of the part as well.
To restore current (1.4.4) behavior, PartHandler would need a default implementation just returning false, and the NullPartHandler would need an implementation returning true if there is a "filename" parameter in the "Content-Disposition" header.
Motivation is a REST server I implemented on top of the HTTP services. The caller might not include the filename parameter, but the RequestHandlers might depend on part-specific headers, which are not caught by the simple form handling of HTMLForm. Specialized PartHandlers can solve this easily.