Dealing with strings in beast::http::message

[Vinnie Falco]

Currently beast::http::message uses individual strings for the url, reason, and method:

template<bool isRequest, class Body, class Headers>
struct message
{
    std::string url;
    std::string method;
    ...
    Headers headers;
    typename Body::value_type body;
};

Instead, we could use the headers container with special character for the field name. For example, the url could go in the headers with the field name ":url". This by the way, is the solution used by HTTP/2. The headers container has allocator support.

[Vinícius dos Santos Oliveira]

Sorry about the delay to reply the message. I was wasting time trying to register the group on gmane to make sure we'll always have mailing list archives.

2016-04-29 7:22 GMT-03:00 Vinnie Falco <vinnie...@gmail.com>:

Instead, we could use the headers container with special character for the field name. For example, the url could go in the headers with the field name ":url". This by the way, is the solution used by HTTP/2. The headers container has allocator support.

I don't like this idea because it's not very type-safe. You could easily mistreat a response message like a request message under this model.

It also goes against the principles that allow other languages do things like "never null guarantee". In this model, ":url" might just not be filled.

--

Vinícius dos Santos Oliveira

https://vinipsmaker.github.io/

[Vinnie Falco]

> I don't like this idea because it's not very type-safe. You could easily
> mistreat a response message like a request message under this model.

That is true. But at least you still have the template argument,
although it would have less effect (or no effect) on the members.

> It also goes against the principles that allow other languages do things
> like "never null guarantee". In this model, ":url" might just not be filled.

That's true, but the same could happen now. A default constructed
message has an empty url field. If we switch to accessor functions,
they could perform the checks for you.

I'm not pushing hard for this idea, just pointing it out as an
alternative. It does solve the problem of allocator support. As I said
before, I don't think its a problem for us now. But during review I am
sure someone is going to bring it up and its probably a good idea to
have alternatives in mind.

[Vinícius dos Santos Oliveira]

Sorry about the HUGE delay.

I've been crazily busy with other projects.

2016-05-02 7:37 GMT-03:00 Vinnie Falco <vinnie...@gmail.com>:

> It also goes against the principles that allow other languages do things
> like "never null guarantee". In this model, ":url" might just not be filled.

That's true, but the same could happen now. A default constructed
message has an empty url field. If we switch to accessor functions,
they could perform the checks for you.

Well... that's how it works.

At least you can have more options. If it is an acessor function, you can use the map to store the url or dedicate a data member exclusively to that. However, it'll be impossible to reference a non-existing member (even if this member is empty).

I'm not pushing hard for this idea, just pointing it out as an
alternative. It does solve the problem of allocator support. As I said
before, I don't think its a problem for us now. But during review I am
sure someone is going to bring it up and its probably a good idea to
have alternatives in mind.

Okay.