No way to iterate through ceylon.net.http.server.Request header fields.

[karlkeskyla]

If header fields are unknown for request, current way would be to try to ask all of them (https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Request_fields) one by one.

[gavinking]

+1.

[luolong]

Using the well known header names is not a viable work-around either, as many services have their own slew of custom headers.

[karlkeskyla]

Another issue is naming - header and headers is confusing. For example, by asking for headers, one would expect to get them all.

[luolong]

To be more precise.

Currently ceylon.http.server.Request class has two methods:

shared interface Request {
    ...
    "Returns a single header with given name."
    shared formal String? header(String name);

    "Returns all headers with given name."
    shared formal String[] headers(String name);
    ...
}

So the most obvious method name for asking for a full sequence of header name/value pairs is already taken: headers

(and the same pattern can be observed with attributes like queryParameters and formParameters)

[tombentley]

Oh, it's even worse than this; the ceylon.http.client::Response has shared List<Header> headers and shared Map<String,Header> headersByName, so it's not even consistent between server and client.

[luolong]

yeah ... I guess we should make it consistent. But that is backwards incompatible change!

[luolong]

Okay, there are few issues brough up here that are somewhat intertwined:

1. API between ceylon.http.server and ceylon.http.client in inconsistent.
2. Neither library offers an easy way to enumerate over all header values

Ditto for parameters.

[luolong]

It should be an easy fix, but it will break API compatibility in a big way.

We should have probably fixed this while we moved the API from ceylon.net module to three separate modules, but that boat has sailed for now ...

What's the plan? Break API compatibility again?

If we break it, what is going to be the new version of ceylon.http.* modules? According to SemVer rules, this is a major version upgrade, but I would hesitate breaking the parity between Ceylon version and module versions in such a significant way ...

[bjansen]

According to SemVer

#triggered

[gavinking]

Haha

On Mon, Oct 3, 2016 at 11:10 AM, Bastien Jansen [email protected] wrote:

According to SemVer

[image: image] https://cloud.githubusercontent.com/assets/281528/19032384/b12d7554-8959-11e6-8dcf-2260140ae4b5.png #triggered

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ceylon/ceylon-sdk/issues/572#issuecomment-251059901, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjZhvh58C7UYsIzWYw5k7DahFI7ERjfks5qwMZ6gaJpZM4IbEwi .

Gavin King [email protected] http://profiles.google.com/gavin.king http://ceylon-lang.org http://hibernate.org http://seamframework.org