rossabaker on cats-effect-3
Updated to CE3/FS3; Migration W… core now compiles Restored sbt files to their unf… and 9 more (compare)
rossabaker on gh-pages
updated site (compare)
I don't know all the types there, but if you're doing big ones, they get persisted to a temp file. That means:
parseStreamedFile. If they do, that's an http4s bug.
Multiparta streaming fashion, it should run in constant space with respect to the file sizes.
Partinto a big blob to write at once, you'll have choppy memory usage, but it should still free when you're done. If it's not, make sure nothing in your code is holding a reference to it.
Using a profiler would help a lot in seeing who is really holding the reference.
AuthedRoutesand a middleware that reduces it to
HttpRoutes. If the middleware is able to extract a user from the request all is well. If it fails to extract a user I can't really return 403 because then the routes can't be composed anymore because they respond to all requests.
AuthedRoutesisn't great and I should have code to extract the user in each route where I need one and return 403 where it's appropriate.
Right but that means I get a 404 instead of a 403 if I try to do something legit but fail to pass a user.
yeah fair enough, sounds like the actual logic for that needs to be at route level then as you suspected, or it would in contradiction with
I can't really return 403 because then the routes can't be composed anymore because they respond to all requests.
so perhaps you could have
Either[FailedToExtract, User]as your context
I think you can still do this if you want to keep that extraction in a middleware and use
ContextRoutes. Also I guess
Option[User] is enough
Ref, though it gets unpleasant to think about
Multipartis going to have to buffer it. But large parts are written to a temp file, so that doesn't imply the whole thing is in memory. But if you want to process a huge upload in a streaming fashion, that's probably not what you want.