Some disadvantages of using an embedded webserver

If using an embedded webserver it may be hard to fine-tune the response details.
The webserver takes the clues on what the response should look like,
based on request, and some of the APIs you called while making the response.
However it may be hard to control the specifics.

For example, let's say you receive a request where the client says it speaks
HTTP 1.1 and requests some data. If the length of the data you're sending
back is not known at the moment when you're starting to send the data,
the 1.1 webserver notices that since you aren't setting the content-length header
in the response you are likely to not know the length, and it goes automatically
into chunked-mode. Both Tomcat and Jetty behave this way. This is quite
inflexible. What if the intention was to reply with a HTTP 1.0 message without
specifying content-length header and without using chunked mode? It is not possible
in Tomcat. It is possible in Jetty by using a trick of adding
Connection: Close header.

These kinds of things make using an embedded webserver feel like
using a black box with knobs that cause unknown and strange effects.
"If you don't use Content-Length, we figure you must want chunked-mode.
But if you set Connection: Close, it looks like you don't want to use
chunked-mode."

The general problem is with a poorly designed abstraction layer that hides
the implementation to the point where it becomes hard to understand
what's going on. The benefits of using a library implementing the HTTP protocols
start to outweigh the disadvantages of not being able to tune specific responses.
A better library is designed in a way that empowers the user but doesn't take
away the flexibility.