Le ven. 18 sept. 2020 à 23:57, John Cowan <xxxxxx@ccil.org> a écrit :
>
> 1) I think the most important application of cookies is login; they are much the most flexible way not to have to pass full auth information with every request.  That makes matters pretty simple: a login procedure inserts a cookie <-> username (or whatever) bimapping into the cookie jar, and other procedures get the cookie and can recover the username from it.  The framework might simplify this if it is told the difference between procedures that do and don't require login.

Does it involve a hidden global?

> 2) The params part of a URL should be reduced to a dictionary and provided.

Will do.

> 3) I think prefix matching is good enough for JSON endpoints, but files are another matter: there may not be a straightforward match between where the various assets exist on the disk and where they exist in URL space, which is why regex and replace is probably the Right Thing.

I would like to avoid the regular expression, because a match is enough.

> 4) If we really need this handling of static file paths, then a port is better than a bytevector, as the file may be too big to want to put it in memory.

Ports will do.

> However, I still like the idea of a registration-based server rather than one with dynamic callbacks.

With a registration-based server you need to think about which route
gets called before another, with the dynamic callback the order of
importance is very readable.

> On Fri, Sep 18, 2020 at 2:36 PM Amirouche Boubekki <xxxxxx@gmail.com> wrote:
>>
>> Le ven. 18 sept. 2020 à 17:57, Arthur A. Gleckler
>> <xxxxxx@speechcode.com> a écrit :
>> >
>> > On Fri, Sep 18, 2020 at 8:39 AM Amirouche Boubekki <xxxxxx@gmail.com> wrote:
>> >
>> >>
>> >> I am not sure what is the point of the current practice to still use
>> >> cookies, outside the fact that cookies are sent implicitly as part of
>> >> every HTTP request.
>> >
>> >
>> > That's an excellent reason by itself, isn't it?
>>
>>
>> I may be wrong about that. I know it is common practice. As far I know
>> HTTP cookies are also a can or jar of worm in the sense they are
>> relatively complex to configure correctly. Again I do not know
>> all-the-things.
>>
>> While writing a pre-srfi, I figured if we support cookies as part of
>> the request, we also need to support them as part of the response,
>> which somewhat complicates things.
>>
>> See https://github.com/pre-srfi/hyperserver#specification

--
Amirouche ~ https://hyper.dev