You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I already have some code from an earlier version of Reactor that uses the Apache Commons httpcomponents core classes for doing HTTP parsing. It's actually quite straightforward and would be an easy way to get HTTP support on top of a raw TCP Reactor.
I also have some custom parsing code that has no dependencies on anything but the JDK. That also might be useful in case the user decided they didn't want to depend on the httpcomponents library. Making the HttpCodec pluggable, then, would allow different parsing implementations to be plugged in, depending on the use case.
If the HTTP parsing classes in Jetty or Tomcat were usable directly, we could also provide implementations that used those classes in case the deployment platform was already one of those servers. I haven't looked to see if this is possible yet, but it would be interesting to find that out.
The text was updated successfully, but these errors were encountered:
Going to close this particular issue as it's been obsoleted by recent changes in reactor-tcp. We should create a new ticket for HTTP support that is more than just a codec.
I already have some code from an earlier version of Reactor that uses the Apache Commons httpcomponents core classes for doing HTTP parsing. It's actually quite straightforward and would be an easy way to get HTTP support on top of a raw TCP Reactor.
I also have some custom parsing code that has no dependencies on anything but the JDK. That also might be useful in case the user decided they didn't want to depend on the httpcomponents library. Making the HttpCodec pluggable, then, would allow different parsing implementations to be plugged in, depending on the use case.
If the HTTP parsing classes in Jetty or Tomcat were usable directly, we could also provide implementations that used those classes in case the deployment platform was already one of those servers. I haven't looked to see if this is possible yet, but it would be interesting to find that out.
The text was updated successfully, but these errors were encountered: