Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 26 2016 19:32
    Build #110 passed
  • Feb 26 2016 19:29
    Build #109 passed
  • Feb 26 2016 19:27

    kolektiv on 3.0.0

    (compare)

  • Feb 26 2016 19:25

    kolektiv on master

    Update RELEASE_NOTES.md (compare)

  • Feb 26 2016 19:25
    Build #108 passed
  • Feb 26 2016 19:22
    kolektiv closed #32
  • Feb 26 2016 19:22
    kolektiv commented #32
  • Feb 26 2016 19:21
    kolektiv closed #40
  • Feb 26 2016 19:21

    kolektiv on master

    completing obsolete compatibili… Merge branch 'master' of github… Merge pull request #43 from kol… (compare)

  • Feb 26 2016 19:21
    kolektiv closed #43
  • Feb 26 2016 19:20
    Build #107 passed
  • Feb 26 2016 19:17
    kolektiv opened #43
  • Feb 26 2016 18:56
    Build #106 passed
  • Feb 26 2016 18:53

    kolektiv on master

    backwards compatibility shims u… Merge pull request #42 from kol… (compare)

  • Feb 26 2016 18:53
    kolektiv closed #42
  • Feb 15 2016 22:46
    mexx commented #34
  • Feb 15 2016 20:16
    Build #105 passed
  • Feb 15 2016 20:14
    kolektiv commented #34
  • Feb 15 2016 20:13
    kolektiv closed #34
  • Feb 15 2016 20:13
    kolektiv commented #34
Ryan Riley
@panesofglass
yes
Ryan Riley
@panesofglass
How would you parse ";" + SP into a list that you would then again parse for each item?

I'm converting

type Cookie =
    | Cookie of CookiePair

into

type Cookie =
    | Cookie of CookiePair list
I think the same is possible for the Set-Cookie header, as well.
Andrew Cherry
@kolektiv
the types Cookie and SetCookie in State.fs are probably what you should parse to - CookiePair doesn't need exposing directly now
from an fparsec perspective, something like sepBy "; "
but i suspect this might take some playing with! i'll try and have a proper look later :)
Ryan Riley
@panesofglass
nm; looks like Set-Cookie supports one cookie at a time.
That's right. Thanks! It's been awhile since I played with FParsec.
Andrew Cherry
@kolektiv
Set-Cookie does - the difficulty is in allowing for the two ways OWIN would allow multiple instances of set-cookie to end up in the dict
(either a single string containing multiple headers, or multiple strings containing one header - both in a string array)
(or, technically, a mix!)
Ryan Riley
@panesofglass
hmm, I don't see where Set-Cookie allows multiple cookies in the same Set-Cookie header.
In which section did you see that?
The grammar for Cookie, however, certainly makes it clear multiple cookie pairs may be included in one header.

Also, for OWIN, the idea is that we don't change what's sent. So if you had:

Cookie: cookie1=foo; cookie2=bar
Cookie: cookie3=baz

you would get a dictionary like this:

[
    "Cookie",
    [|
        "cookie1=foo; cookie2=bar"
        "cookie3=baz"
    |]
]
Andrew Cherry
@kolektiv
ah no, not in the http spec, but the owin one
and yeah, maintaining the state is also awkward, especially as a lens/prism as they're stateless
Ryan Riley
@panesofglass
If that's not clear in the OWIN spec, we should add a note to clarify that.
Andrew Cherry
@kolektiv
"Header values are assumed to be in a mixed format, meaning that a normally comma separated header may appear as a single entry in the values array, one entry per value, or a mixture of the two. (e.g. new string[1] {"value, value, value"}, new string[3] {"value", "value", "value"}, or new string[2] {"value, value", "value"})"
Ryan Riley
@panesofglass
OWIN's goal is to make the values available and not to change them.
Andrew Cherry
@kolektiv
i may have misinterpreted that in terms of what it means for valid repeated headers
but it does make things non-trivial i think
Ryan Riley
@panesofglass
oh, I don't recall that bit of text. :(
oh, yes, now I recall it.
Andrew Cherry
@kolektiv
yeah. it's the bit of the owin spec which has so far caused me to think "sod this, i'll deal with that later"
unfortunately, that appears to be now!
Ryan Riley
@panesofglass
I think the idea was meant to convey that we wouldn't change what was returned, so you may have to look for the many possible combinations.
We should clarify that bit.
Andrew Cherry
@kolektiv
yeah. it's a bit of a pain, that's for sure, as think we're going to need to do something interesting with a lens to try and maintain format. will have a think!
right, time to head for a train. catch you later!
Ryan Riley
@panesofglass
Thoughts: owin/owin#47
Andrew Cherry
@kolektiv
cool! i'll have a play later with some simple test cases
Ryan Riley
@panesofglass
Here's where I'm at:
type Cookie =
    | Cookie of CookiePair list

    static member internal Mapping =

        let cookieP =
                CookiePair.Mapping.Parse
            // TODO: optionally followed by ; + SP
            // TODO: many into a list
            |>> Cookie

        let cookieF =
            function | Cookie pairs ->
                        String.Join("; ",
                                    [| for c in pairs do
                                        yield CookiePair.Mapping.Format c |])
                     |> append

        { Parse = cookieP
          Format = cookieF }

    (* Lenses *)

    static member Cookie_ =
        (fun (Cookie c) -> c), (fun c -> Cookie c)

    (* Common *)

    static member Format =
        Formatting.format Cookie.Mapping.Format

    static member Parse =
        Parsing.parse Cookie.Mapping.Parse

    static member TryParse =
        Parsing.tryParse Cookie.Mapping.Parse

    override x.ToString () =
        Cookie.Format x
Ryan Riley
@panesofglass
Fixed! See freya-fs/arachne#15
Andrew Cherry
@kolektiv
cool! i think i can simplify that a bit with some helpers that we have too
would you be able to point the pull request at my fork for now? at the moment state isn't part of public arachne, as it's definitely not production ready!
Ryan Riley
@panesofglass
sure
See kolektiv/arachne#1
Ryan Riley
@panesofglass
As a note, the purpose of the current versioning is that we can preview public builds (once things reach master) and otherwise reference nuget builds from PRs to try things out.
However that only happens on PRs to freya-fs/arachne, not other branches.
Andrew Cherry
@kolektiv
there's now a pull request including http.state in to master (cookie support!) - hopefully this will be handy for people :)
See freya-fs/arachne#17 ...
Ryan Riley
@panesofglass
w00t!
Ryan Riley
@panesofglass
Preliminary cookie support is now available: https://www.nuget.org/packages/Arachne/2.3.27-b063
NOTE: this is a pre-release.
Ryan Riley
@panesofglass
@kolektiv can you help me with panesofglass/websharper.owin#1 ?
Ryan Riley
@panesofglass
Mind if I tag a release for Arachne.Http.State?
Andrew Cherry
@kolektiv
no objections :)