Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Márk Sági-Kazár
    @sagikazarmark
    AFAIK there is some cookie support in ivory http adapter
    David de Boer
    @ddeboer
    Should we have a look at that first?
    Márk Sági-Kazár
    @sagikazarmark
    if there is, it will certainly be migrated at some point
    David de Boer
    @ddeboer
    I say we shouldn’t be too scared to break stuff, though. ;)
    Márk Sági-Kazár
    @sagikazarmark
    Break stuff?
    David de Boer
    @ddeboer
    Well I mean to implement it in a new way and break the old one.
    Márk Sági-Kazár
    @sagikazarmark
    Why should we need to break anything to implement cookies? I agree anyway
    David de Boer
    @ddeboer
    Okay, but there’s currently no event support in the adapters, right? So this subscriber would rather apply to the adapter client.
    Márk Sági-Kazár
    @sagikazarmark
    There will be event support
    David de Boer
    @ddeboer
    But setting the cookies Guzzle 5/6 style should happen in the adapters.
    Márk Sági-Kazár
    @sagikazarmark
    I think it should work as an adapter decorator
    David de Boer
    @ddeboer
    Interesting, how exactly?
    Márk Sági-Kazár
    @sagikazarmark
    similarly to the current implementation in ivory
    there will be support for both symfony and league event dispatchers
    David de Boer
    @ddeboer
    Right.
    Márk Sági-Kazár
    @sagikazarmark
    I think a subscriber method would be more general than allowing cookies in options
    David de Boer
    @ddeboer
    But still the adapters themselves are responsible for setting the cookies in a client-specific way.
    (e.g., G5 allows a plain array, G6 requires a CookieJar etc.)
    Márk Sági-Kazár
    @sagikazarmark
    Right
    Not completely sure how that worked with subscribers
    David de Boer
    @ddeboer
    No, trying to figure that out. I’d say that just passing cooking into sendRequest(…, $options) is necessary anyway.
    Márk Sági-Kazár
    @sagikazarmark
    But if it is possible, I think one general solution is better
    David de Boer
    @ddeboer
    I think the general solution could only be in adapter-client.
    Márk Sági-Kazár
    @sagikazarmark
    Probably yes, I am not completely familiar with the whole adapter yet
    David de Boer
    @ddeboer
    I can imagine.
    Márk Sági-Kazár
    @sagikazarmark
    But cookie is something that could also be generalized as an option
    David de Boer
    @ddeboer
    Yes, that’s what I mean, a general ‘cookie’ $option.
    And then have a subscriber in adapte-rclient that sets that option.
    So in ivory, there’s a CookieJar that you use to manipulate the req/read from the response.
    I think that only works with InternalRequests, but PSR-7 requests have no cookies.
    (well the server reqs do, but we need client reqs)
    Márk Sági-Kazár
    @sagikazarmark
    I think the InternalRequest only used because all requests are converted into internal requests in ivory
    If we can make a solution which is PSR-7 and not HTTP Client specific, that would be better I think
    David de Boer
    @ddeboer
    Agreed, but the adapters will always be client-specific, so cookies need to be passed into them somehow. I think the options make sense, that’s what Guzzle does, too.
    Márk Sági-Kazár
    @sagikazarmark
    php-http/adapter#35
    @ddeboer I checked the guzzle implementation and at some point it simply serializes the cookie jar and places it in the request (which means it is not really guzzle specific)
    I think options should be used only for configurations which cannot be passed otherwised (eg. coded in header, like cookies)
    An event dispatcher solution is better IMO because you can use the same strategy for ALL adapters
    the event dispatcher adapter is a regular adapter which wraps another and emits events during it's lifecycle
    I am not completely happy with that solution though
    so I am thinking about implementing a plugin adapter
    which could utilize a similar middleware architecture to what I did it in port
    Márk Sági-Kazár
    @sagikazarmark
    my main problem with an event-driven solution is that PSR-7 messages are immutable, thus in every listener I would have to set the request/response in the event if I modify it
    in a middleware architecture it is not a problem
    the other ugly solution would be using decorators
    which is similar
    but that would be ugly as well