On Sat, 2 Jun 2018 at 16:52, Jaikiran Pai <jai.forums2...@gmail.com> wrote:
> 2. Would it be a good idea to add APIs (perhaps in HttpHeaders class) to
> return values of higher level constructs represented by the headers.
> Imagine certain well-known headers in the response, like Content-Length
> and Content-Type. Would it be a good idea to expose higher level APIs of
> the form getContentLength(), getContentCharset() and such? It probably
> doesn't add much value to Content-Length header but there's a particular
> mechanism the charset is supposed to be parsed out of the "Content-Type"
> header and having it done with the API's implementation would prevent
> all the parsing/logic in every other application.
>
-1 on getContentLength, it's a detail of handling the message, it often
won't be there (eg chunked encoding in HTTP 1.1 or regular content length
less in HTTP 2), and so it should only be relevant to the BodyHandler (or
whatever it's called now, I forget which APIs have been renamed to what). I
don't think that's an important enough use case, nor do I think it adds
enough value, to warrant support in the API.
+1 on variants of getContentType that give you either the media type or the
charset parsed from the content type header. Without them, we're going to
end up with a lot of regexps doing ad hoc parsing to get the information
needed out of the Content-Type header. For example, if you want to know if
the incoming request is application/json, text/plain, or application/xml,
in order to parse that correctly, you'll need to do things like
.matches("text/plain(?;.*)?"). Whereas, if you had a getMediaType() you
could just do a .equals("text/plain").
--
*James Roper*
*Senior Developer, Office of the CTO*
Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
