I think the issue is from

Since
JuliaLang/julia#53896

calling String on a view of a Memory and then trying to use the Memory is unsafe.

Here is a example:

julia> a = Memory{UInt8}(undef, 10);

julia> fill!(a, 0x01);

julia> String(view(a, 1:2))
"\x01\x01"

julia> a
0-element Memory{UInt8}

from http.jl.

Yeah, I think all the uses of the IOBuffer internals has to be removed.

#1145 and #1147 has started that work.

from http.jl.

This is not the only issue with julia 1.11-beta, running pkg>test HTTP results in a very long list of errors.

from http.jl.

I am seeing a similar issue when processing the body of a POST request, see issue above on the Oxygen.jl repo for details.

from http.jl.

Does anyone have a simple repro for this?

from http.jl.

Server

using Oxygen
using HTTP
using StructTypes

struct Login
    user_name::String
end

@post "/login" function(req::HTTP.Request)
    @info req.body
    login_data = json(req, Login)
    @info login_data
    return "hello world!"
end

# start the web server
serve()

Client

using HTTP
HTTP.post("http://127.0.0.1:8080/login", body = "{ \"user_name\": \"test\" }")

from http.jl.

You can see what the exception that Client call generates on the Server while running on Julia 1.11 here -> OxygenFramework/Oxygen.jl#186 (comment)

from http.jl.

In theory, a normal readbyte call there could allocate a StringVector more directly here, avoiding the copy later to make a String from this, and avoid relying on implementation details too

from http.jl.

I agree we need to refactor a bunch of the internals to not abuse IOBuffer; either move everything to be Memory-based (my preference since we'll have full control and want to be efficient as possible w/ # of allocations), or just use IOBuffer's properly. In any case, I think #1170 is at least a stop-gap for the immediate issue posted here.

from http.jl.