On Tue, Feb 7, 2012 at 10:28 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
I have been looking around at possibly making a Browser module for
Network.HTTP.Conduit on top of Control.Monad.State. I came across this
roadbump:
In order to implement redirection following, client code must
On Wed, Feb 8, 2012 at 6:28 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
I have been looking around at possibly making a Browser module for
Network.HTTP.Conduit on top of Control.Monad.State. I came across this
roadbump:
In order to implement redirection following, client code must
Michael Snoyman wrote:
Actually, this is just a setting: you can override with checkStatus[1].
[1]
http://hackage.haskell.org/packages/archive/http-conduit/1.2.4/doc/html/Network-HTTP-Conduit.html#v:checkStatus
Absolutely! I use that in my http-proxy package [0]. Elegant and easy
to use.
Just an FYI for everyone: Myles sent an (incredibly thorough) pull
request to handle cookies:
https://github.com/snoyberg/http-conduit/pull/13
Thanks!
On Sun, Feb 5, 2012 at 8:20 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
1. The spec defines a grammar for the attributes. They're in
After all these commits have been flying around, I have yet another
question:
the 'HTTP' package defines Network.Browser which is a State monad which
keeps state about a browser (i.e. a cookie jar, a proxy, redirection
parameters, etc.) It would be pretty straightforward to implement this kind
of
I would say: if it adds no package dependencies, put it right in.
Aristid
Am 06.02.2012 22:09 schrieb Myles C. Maxfield myles.maxfi...@gmail.com:
After all these commits have been flying around, I have yet another
question:
the 'HTTP' package defines Network.Browser which is a State monad
+1
On Mon, Feb 6, 2012 at 11:16 PM, Aristid Breitkreuz
arist...@googlemail.com wrote:
I would say: if it adds no package dependencies, put it right in.
Aristid
Am 06.02.2012 22:09 schrieb Myles C. Maxfield myles.maxfi...@gmail.com:
After all these commits have been flying around, I have
Is it possible to have both an Expires and a Max-age? If not, maybe
you should make a type like
data Expiry = NeverExpires | ExpiresAt UTCTime | ExpiresIn DiffTime
2012/2/4 Myles C. Maxfield myles.maxfi...@gmail.com:
Here is the patch to Web.Cookie. I didn't modify the tests at all because
That's a pretty reasonable thing to do.
Didn't you say that I should keep the 'prefer max-age to expires' logic out
of Web.Cookie?
What do you think, Michael?
--Myles
On Sat, Feb 4, 2012 at 4:03 AM, Aristid Breitkreuz
arist...@googlemail.comwrote:
Is it possible to have both an Expires and a
Looks good, a few questions/requests:
1. Is there a reason to upper-case all the attributes?
2. Is the time = 1.3 a requirements? Because that can cause a lot of
trouble for people.
3. Can you send the patch as a Github pull request? It's easier to
track that way.
Michael
On Sat, Feb 4, 2012 at
1. The spec defines a grammar for the attributes. They're in uppercase.
2. Yes - 1.3 is the first version that lists DiffTime as an instance of
RealFrac (so I can use the 'floor' function to pull out the number of
seconds to render it)
3. I'll see what I can do.
--Myles
On Sat, Feb 4, 2012 at
Here is the patch to Web.Cookie. I didn't modify the tests at all because
they were already broken - they looked like they hadn't been updated since
SetCookie only had 5 parameters. I did verify by hand that the patch works,
though.
Thanks,
Myles
On Thu, Feb 2, 2012 at 11:26 PM, Myles C.
Alright. After reading the spec, I have these questions / concerns:
- The spec supports the Max-Age cookie attribute, which Web.Cookies
doesn't.
- I see two possible solutions to this. The first is to have
parseSetCookie take a UTCTime as an argument which will represent the
Sounds good. I think the nicest way to handle maxage would be changing
SetCookie, not handling it at parsing time.
Aristid
Am 03.02.2012 05:35 schrieb Myles C. Maxfield myles.maxfi...@gmail.com:
Alright. After reading the spec, I have these questions / concerns:
- The spec supports the
Looks good to me too. I agree with Aristid: let's make the change to
cookie itself. Do you want to send a pull request? I'm also
considering making the SetCookie constructor hidden like we have for
Request, so that if in the future we realize we need to add some other
settings, it doesn't break
Alright, I'll make a small patch that adds 2 fields to SetCookie:
setCookieMaxAge :: Maybe DiffTime
setCookieSecureOnly :: Bool
I've also gotten started on those cookie functions. I'm currently writing
tests for them.
@Chris: The best advice I can give is that Chrome (what I'm using as a
source
You mean you're *not* making this proposal?
On Wed, Feb 1, 2012 at 7:30 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
Well, this is embarrassing. Please disregard my previous email. I should
learn to read the RFC *before* submitting proposals.
--Myles
On Tue, Jan 31, 2012 at 6:37
Nope. I'm not. The RFC is very explicit about how to handle cookies. As
soon as I'm finished making sense of it (in terms of Haskell) I'll send
another proposal email.
On Feb 1, 2012 3:25 AM, Michael Snoyman mich...@snoyman.com wrote:
You mean you're *not* making this proposal?
On Wed, Feb 1,
Here are my initial ideas about supporting cookies. Note that I'm using
Chrome for ideas since it's open source.
- Network/HTTP/Conduit/Cookies.hs file
- Exporting the following symbols:
- type StuffedCookie = SetCookie
- A regular SetCookie can have Nothing for its Domain
Well, this is embarrassing. Please disregard my previous email. I should
learn to read the RFC *before* submitting proposals.
--Myles
On Tue, Jan 31, 2012 at 6:37 PM, Myles C. Maxfield myles.maxfi...@gmail.com
wrote:
Here are my initial ideas about supporting cookies. Note that I'm using
On Sat, Jan 28, 2012 at 1:20 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
the fromJust should never fail, beceause of the guard statement:
| 300 = code code 400 isJust l'' isJust l' = Just $ req
Because of the order of the operators, it will only evaluate fromJust
after it
Ah, yes, you're completely right. I completely agree that moving the
function into the Maybe monad increases readability. This kind of function
is what the Maybe monad was designed for.
Here is a revised patch.
On Sat, Jan 28, 2012 at 8:28 AM, Michael Snoyman mich...@snoyman.comwrote:
On Sat,
Michael Snoyman wrote:
On Sat, Jan 28, 2012 at 1:20 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
the fromJust should never fail, beceause of the guard statement:
| 300 = code code 400 isJust l'' isJust l' = Just $ req
Because of the order of the operators, it will
Thanks, looks great! I've merged it into the Github tree.
On Sat, Jan 28, 2012 at 8:36 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
Ah, yes, you're completely right. I completely agree that moving the
function into the Maybe monad increases readability. This kind of function
is what
the fromJust should never fail, beceause of the guard statement:
| 300 = code code 400 isJust l'' isJust l' = Just $ req
Because of the order of the operators, it will only evaluate fromJust
after it makes sure that the argument isJust. That function in particular
shouldn't throw any
Here is a patch regarding getRedirectedRequest. Comments are very welcome.
--Myles C. Maxfield
On Wed, Jan 25, 2012 at 10:21 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
I was planning on making the caller deal with keeping track of cookies
between requests. My cookie idea only
I'm a little worried about the use of `fromJust`, it will give users a
very confusing error message, and the error might be trigged at the
wrong point in the computation. I'd feel better if checkRedirect lived
in either some Failure, an Either, or maybe even in IO itself. IO
might make sense if we
The nice thing is that this way, nobody can force me to handle cookies. ;-)
Might be that usage patterns emerge, which we can then codify into
functions later.
Am 25.01.2012 08:09 schrieb Michael Snoyman mich...@snoyman.com:
On Wed, Jan 25, 2012 at 9:01 AM, Myles C. Maxfield
Alright, that's fine. I just wanted to be explicit about the interface we'd
be providing. Taking the Request construction code out of 'http' and
putting it into its own function should be a quick change - I'll have it to
you soon. One possible wrench - The existing code copies some fields (like
On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
Alright, that's fine. I just wanted to be explicit about the interface we'd
be providing. Taking the Request construction code out of 'http' and putting
it into its own function should be a quick change - I'll
I was planning on making the caller deal with keeping track of cookies
between requests. My cookie idea only solves the problem of cookies
persisting through a redirect chain - not between subsequent request chains.
Do you think that Network.HTTP.Conduit should have a persistent cookie jar
On Mon, Jan 23, 2012 at 10:43 PM, Michael Snoyman mich...@snoyman.comwrote:
On Tue, Jan 24, 2012 at 8:37 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
I have attached a patch to add a redirect chain to the Response datatype.
Comments on this patch are very welcome.
I thought that
On Tue, Jan 24, 2012 at 6:57 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
On Mon, Jan 23, 2012 at 10:43 PM, Michael Snoyman mich...@snoyman.com
wrote:
On Tue, Jan 24, 2012 at 8:37 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
I have attached a patch to add a redirect chain
Sorry, I don't think I'm following. What would the meaning of the value
returned from checkRedirect be?
--Myles
On Tue, Jan 24, 2012 at 10:47 AM, Michael Snoyman mich...@snoyman.comwrote:
On Tue, Jan 24, 2012 at 6:57 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
On Mon, Jan 23,
Yeah, a more combinatorial approach to making HTTP requests would be
good. So +1 for checkRedirect or anything similar.
2012/1/24 Michael Snoyman mich...@snoyman.com:
On Tue, Jan 24, 2012 at 6:57 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
On Mon, Jan 23, 2012 at 10:43 PM, Michael
It would be the new request indicated by the server response, if the
server gave a redirect response.
On Tue, Jan 24, 2012 at 9:05 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
Sorry, I don't think I'm following. What would the meaning of the value
returned from checkRedirect be?
Sorry, I think I'm still a little confused about this.
From the point of view of a library user, if I use the 'http' function, but
want to know what final URL I ended up at, I would have to set redirects to
0, call http, call checkRedirect, and recurse until checkRedirect returns
Nothing (or a
On Wed, Jan 25, 2012 at 9:01 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
Sorry, I think I'm still a little confused about this.
From the point of view of a library user, if I use the 'http' function, but
want to know what final URL I ended up at, I would have to set redirects to
0,
Rejecting cookies is not without precedent.
If you must force cookie handling upon us, at least make it possible to
selectively reject them.
Aristid
Am 23.01.2012 08:44 schrieb Michael Snoyman mich...@snoyman.com:
That's a violation of the spec. Having a server set a cookie and then
not
On Mon, Jan 23, 2012 at 1:20 PM, Aristid Breitkreuz
arist...@googlemail.com wrote:
Rejecting cookies is not without precedent.
If you must force cookie handling upon us, at least make it possible to
selectively reject them.
Aristid
If you turn off automatic redirects, then you won't have
I have attached a patch to add a redirect chain to the Response datatype.
Comments on this patch are very welcome.
I was originally going to include the entire Request object in the
redirection chain, but Request objects are parameterized with a type 'm',
so including a 'Request m' field would
On Tue, Jan 24, 2012 at 8:37 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
I have attached a patch to add a redirect chain to the Response datatype.
Comments on this patch are very welcome.
I thought that this isn't necessary since a client wanting to track
all the redirects could just
Replies are inline. Thanks for the quick and thoughtful response!
On Sat, Jan 21, 2012 at 8:56 AM, Michael Snoyman mich...@snoyman.comwrote:
Hi Myles,
These sound like two solid features, and I'd be happy to merge in code to
support it. Some comments below.
On Sat, Jan 21, 2012 at 8:38 AM,
On Sun, Jan 22, 2012 at 11:07 PM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
Replies are inline. Thanks for the quick and thoughtful response!
On Sat, Jan 21, 2012 at 8:56 AM, Michael Snoyman mich...@snoyman.com
wrote:
Hi Myles,
These sound like two solid features, and I'd be happy
1. Oops - I overlooked the fact that the redirectCount attribute of a
Request is exported (it isn't listed on the
documentationhttp://hackage.haskell.org/packages/archive/http-conduit/1.2.0/doc/html/Network-HTTP-Conduit.html
probably
because the constructor itself isn't exported. This seems like a
On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
1. Oops - I overlooked the fact that the redirectCount attribute of a
Request is exported (it isn't listed on the documentation probably because
the constructor itself isn't exported. This seems like a flaw in
Just make sure Cookie handling can be disabled completely.
Aristid
Am 23.01.2012 07:44 schrieb Michael Snoyman mich...@snoyman.com:
On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
1. Oops - I overlooked the fact that the redirectCount attribute of a
Alright, that sounds good to me. I'll get started on it (the IORef idea).
Thanks for the insight!
--Myles
On Sun, Jan 22, 2012 at 10:42 PM, Michael Snoyman mich...@snoyman.comwrote:
On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
1. Oops - I overlooked the
The only times cookies would be used would be:
1. If you explicitly use it.
2. If you have redirects turned on, and a page that redirects you also
sets a cookie.
I would think that we would want (2) to be on regardless of user
setting, do you disagree?
Michael
On Mon, Jan 23, 2012 at 8:46 AM,
I'm a little confused as to what you mean by 'cookie handling'. Do you mean
cookies being set inside redirects for future requests inside the same
redirect chain, or users being able to supply cookies to the first HTTP
request and pull them out of the last HTTP response?
Clearly, making the
Indeed, I disagree on 2. Sometimes there is an API and cookies are just not
part of it (and redirects are).
Aristid
Am 23.01.2012 08:16 schrieb Michael Snoyman mich...@snoyman.com:
The only times cookies would be used would be:
1. If you explicitly use it.
2. If you have redirects turned on,
That's a violation of the spec. Having a server set a cookie and then
not really mean it or something along those lines would be invalid.
And having a server not set a cookie at all means having this feature
would be irrelevant.
On Mon, Jan 23, 2012 at 9:42 AM, Aristid Breitkreuz
Hi Myles,
These sound like two solid features, and I'd be happy to merge in code to
support it. Some comments below.
On Sat, Jan 21, 2012 at 8:38 AM, Myles C. Maxfield myles.maxfi...@gmail.com
wrote:
To: Michael Snoyman, author and maintainer of http-conduit
CC: haskell-cafe
Hello!
I am
Myles C. Maxfield wrote:
I am interested in contributing to the http-conduit library. I've been
using it for a little while and reading through its source, but have felt
that it could be improved with two features:
- Allowing the caller to know the final URL that ultimately resulted in
54 matches
Mail list logo
