aws_http_stream_get_incoming_request_uri could be named better?

[quinnj]

It seems like aws_http_stream_get_incoming_request_uri would be better named as aws_http_stream_get_incoming_request_path since it's not actually returning an aws_uri object, but just the request path as a byte cursor. I wondered initially if it was doing something fancy like building a full uri string (using incoming request scheme, host, etc.), but with a peek at the implementation, it seems to be just the path.

[graebm]

Good point.
Can I ask out of curiosity how you stumbled across this?
While the client-side of this API is in active use, the server-side is (which would use this function) ... somewhat neglected, which is how something like this escaped notice.

The client and server APIs were initially built at the same time, but over the years we (here in AWS SDK libraries) only found uses for the client code.

[quinnj]

Yeah, I'm the primary developer/maintainer of the HTTP.jl (Julia language) package which is one of the foundational packages in the Julia ecosystem for client/server functionality. There are a few client alternatives based on curl/nghttp/etc, but HTTP.jl has been the closest to a "pure Julia" solution.

It's become clear over the years though of 1) trying to maintain the package and manage the long-tail of bug reports that have come in and 2) working with various industrial applications (including a few of my own at various companies), that the current HTTP.jl architecture isn't ideal. We use a combination of libuv for low-level IO/sockets/event-looping, plus Julia's own "partr" multithreading/task scheduling, plus OpenSSL for TLS. The amount of complexity though trying to glue together all the C-wrappers + Julia internals is unwieldy. I've become much more a fan of webstacks that are completely vertically integrated like the Go standard libraries (net, http, etc.) and the aws-crt libraries, because the APIs are built to actually coordinate/work together and you don't run into bottlenecks with different systems that weren't necessarily designed with the others in mind.

All that to say, I'm working on a branch (JuliaWeb/HTTP.jl@master...jq-http2) where I'm rewriting the HTTP.jl library to use the aws-crt libraries under the hood. The client side is pretty much done and seems to work fantastic, blowing past the old implementation in terms of total network bandwidth saturation capabilities. I've been switching the server side over, which has also gone pretty smoothly, but I have noticed it doesn't seem to have the same level of control or detail as the client side.

I think that's probably fine because the HTTP.jl server code isn't primarily designed as the most outward facing server where you need all the bells and whistles of a full nginx, but more as an internal microservice server that would be proxied to from a gateway server.

As I dive more into the code, I'd be happy to help contribute if there's interest in improving things. If there isn't a long-term plan to maintain teh server functionality at all though, that would be helpful to know at this point so I can pivot the server side. I'd have a pretty strong interest in helping contribute/maintain the server side though because the consistency between the two for the HTTP.jl package would be phenomenal and worth it in my mind to put in effort to help. And like I mentioned, I don't think the HTTP.jl server requirements are super advanced, so keeping the basics maintained would mostly likely be sufficient.

[graebm]

There aren't plans to maintain the server side. The HTTP/2 implementation doesn't support it at all (There are bits and pieces of low level stuff we did while we were knee deep in the RFC, but there's still a lot missing)

I've wanted to remove the server stuff for some time, so we can simplify the client code we do use, but it's hard to justify work where any change might introduce bugs. (I'd similarly like to remove support for HTTP/1.1 pipelining which adds a lot of complexity and is never used).

Sorry this led to you wasting time. I'll look into marking these functions deprecated, maybe move them into private headers, maybe delete them entirely, but need to do more research to confirm no one is using them...

[quinnj]

I'd appreciate it if the server code could be kept as-is at least, and I'd be happy to help contribute/maintain, even without the HTTP/2 support. Being able to do the basic server socket + accept callback, request parsing, then response sending shouldn't be that complex and provides a really nice consistency for use.

I agree that removing pipelining would definitely be worth the reduction in complexity. We did the same thing in HTTP.jl a little over a year ago.