ALPHA: http-types 0.1

Aristid Breitkreuz

3 Feb 2011 3 Feb '11

4:42 p.m.

Hi, I just wanted to announce that I uploaded a first version of http-types to hackage: http://hackage.haskell.org/package/http-types-0.1 This version is very much an Alpha version. And, uh, do give feedback: I promise that I will keep myself better in check, this time. Aristid

Attachments:

attachment.html (text/html — 460 bytes)

Show replies by date

Michael Snoyman

3 Feb 3 Feb

4:53 p.m.

On Thu, Feb 3, 2011 at 11:42 PM, Aristid Breitkreuz wrote:

...

Hi, I just wanted to announce that I uploaded a first version of http-types to hackage: http://hackage.haskell.org/package/http-types-0.1 This version is very much an Alpha version. And, uh, do give feedback: I promise that I will keep myself better in check, this time.

Aristid _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Quick question: how do you create new statuses? Michael

Aristid Breitkreuz

5:19 p.m.

Status 700 "Crazy status" ... but I forgot to export the Status constructor. That was an oversight. I made the same error with HttpVersion. Aristid 2011/2/3 Michael Snoyman

...

On Thu, Feb 3, 2011 at 11:42 PM, Aristid Breitkreuz wrote:

...
Hi, I just wanted to announce that I uploaded a first version of http-types to hackage: http://hackage.haskell.org/package/http-types-0.1 This version is very much an Alpha version. And, uh, do give feedback: I promise that I will keep myself better in check, this time.

Aristid _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Quick question: how do you create new statuses?

Michael

Aristid Breitkreuz

5:23 p.m.

OK, I uploaded a fixed version: http://hackage.haskell.org/package/http-types-0.1.1 Good night! Aristid 2011/2/3 Aristid Breitkreuz

...

Status 700 "Crazy status"

... but I forgot to export the Status constructor. That was an oversight. I made the same error with HttpVersion.

Aristid

2011/2/3 Michael Snoyman

On Thu, Feb 3, 2011 at 11:42 PM, Aristid Breitkreuz

...
wrote:

...
Hi, I just wanted to announce that I uploaded a first version of http-types to hackage: http://hackage.haskell.org/package/http-types-0.1 This version is very much an Alpha version. And, uh, do give feedback: I promise that I will keep myself better in check, this time.

Aristid _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Quick question: how do you create new statuses?

Michael

Michael Snoyman

4 Feb 4 Feb

1:09 a.m.

Alright, everything seems fine to me. Some more comments: * Besides the fact that I think HttpCIByteString is too verbose, it presents another problem: I cannot transparently switch over to it in WAI and http-enumerator. If you kept the same name (CIByteString), I could simply switch over to your version without any breaking changes. * I like methodGet et al. * Do you want to consider some parsing functions? I can provide you the code. Some things I would imagine would be: * parseQueryString :: ByteString -> [(ByteString, Maybe ByteString)] (I'm not sure if in practice anyone cares about the Maybe btw, but you are right that it is more theoretically correct) * renderQueryString :: [(ByteString, Maybe ByteString)] -> ByteString * parsePath :: ByteString -> [String], which would do all splitting-on-slash, percent decoding and UTF-8 decoding * renderPath :: [String] -> ByteString, which would be the reverse of parsePath * renderPathQuery :: [String] -> [(ByteString, ByteString)] -> ByteString * parseHttpAccept :: ByteString -> [ByteString] * Are you planning on adding headers as well? Basically, feel free to raid Network.Wai.Parse[1]. [1] http://hackage.haskell.org/packages/archive/wai-extra/0.3.1/doc/html/Network... On Fri, Feb 4, 2011 at 12:23 AM, Aristid Breitkreuz wrote:

...

OK, I uploaded a fixed version: http://hackage.haskell.org/package/http-types-0.1.1

Good night! Aristid

2011/2/3 Aristid Breitkreuz

...
Status 700 "Crazy status" ... but I forgot to export the Status constructor. That was an oversight. I made the same error with HttpVersion.

Aristid

2011/2/3 Michael Snoyman

...
On Thu, Feb 3, 2011 at 11:42 PM, Aristid Breitkreuz wrote:

...
Hi, I just wanted to announce that I uploaded a first version of http-types to hackage: http://hackage.haskell.org/package/http-types-0.1 This version is very much an Alpha version. And, uh, do give feedback: I promise that I will keep myself better in check, this time.

Aristid _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Quick question: how do you create new statuses?

Michael

Christian Maeder

3:43 a.m.

Am 03.02.2011 22:42, schrieb Aristid Breitkreuz:

...

Hi,

I just wanted to announce that I uploaded a first version of http-types to hackage:

http://hackage.haskell.org/package/http-types-0.1

With your two types Method and MethodADT I would omit "OtherMethod" in MethodADT, since a mere enumeration type is much better: data StdMethod = GET | POST | HEAD | PUT | DELETE | TRACE | CONNECT | OPTIONS deriving (Show, Eq, Ord, Enum, Bounded) method :: StdMethod -> Method method = Ascii.pack . show methodListB :: [(Method, StdMethod)] methodListB = map (\ s -> (method s, s)) [minBound .. maxBound] methodToStdMethod :: Method -> Maybe StdMethod methodToStdMethod = flip lookup methodListB Cheers Christian

Aristid Breitkreuz

5:04 a.m.

Interesting idea. I don't really like that StdMethod cannot encode custom methos though. data Method = Std StdMethod ¦ Ext ByteString Might work. But is the complexity worth it? Am 04.02.2011 09:43 schrieb "Christian Maeder" : Am 03.02.2011 22:42, schrieb Aristid Breitkreuz:

...

Hi,

I just wanted to announce that I uploaded a first version of http-types to hackage:

... With your two types Method and MethodADT I would omit "OtherMethod" in MethodADT, since a mere enumeration type is much better: data StdMethod = GET | POST | HEAD | PUT | DELETE | TRACE | CONNECT | OPTIONS deriving (Show, Eq, Ord, Enum, Bounded) method :: StdMethod -> Method method = Ascii.pack . show methodListB :: [(Method, StdMethod)] methodListB = map (\ s -> (method s, s)) [minBound .. maxBound] methodToStdMethod :: Method -> Maybe StdMethod methodToStdMethod = flip lookup methodListB Cheers Christian

Christian Maeder

5:22 a.m.

Am 04.02.2011 11:04, schrieb Aristid Breitkreuz:

...

Interesting idea. I don't really like that StdMethod cannot encode custom methos though.

For any method (including custom ones) you have the type Method (just a ByteString).

...

data Method = Std StdMethod ¦ Ext ByteString

Might work. But is the complexity worth it?

What complexity? It exactly models that you want to or need to distinguish between custom and standard methods. (Converting "data Method" to and from byte strings is no issue.) Either choice "StdMethod" + "type Method = ByteString" or "StdMethod" + "data Method" (above) is better than "MethodADT". HTH Christian

...

...
data StdMethod = GET | POST | HEAD | PUT | DELETE | TRACE | CONNECT | OPTIONS deriving (Show, Eq, Ord, Enum, Bounded)

method :: StdMethod -> Method method = Ascii.pack . show

methodListB :: [(Method, StdMethod)] methodListB = map (\ s -> (method s, s)) [minBound .. maxBound]

methodToStdMethod :: Method -> Maybe StdMethod methodToStdMethod = flip lookup methodListB

Cheers Christian

Christian Maeder

5:49 a.m.

Am 04.02.2011 11:22, schrieb Christian Maeder:

...

Am 04.02.2011 11:04, schrieb Aristid Breitkreuz:

...
Interesting idea. I don't really like that StdMethod cannot encode custom methos though.

For any method (including custom ones) you have the type Method (just a ByteString).

...
data Method = Std StdMethod ¦ Ext ByteString

Might work. But is the complexity worth it?

What complexity? It exactly models that you want to or need to distinguish between custom and standard methods. (Converting "data Method" to and from byte strings is no issue.)

Either choice "StdMethod" + "type Method = ByteString" or "StdMethod" + "data Method" (above) is better than "MethodADT".

Well, one disadvantage remains for: data Method = Std StdMethod ¦ Ext ByteString 'Std GET' and 'Ext (Ascii.pack "GET")' are different Method values, but identically sent. So "data Method" would need some encapsulation, i.e. "Ext" should be hidden and separate functions to construct methods should be provided. The disadvantage for just strings are possible spelling errors. With constants or constructors spelling errors are detected by the compiler (but you still can confuse constants having the same type). C.

Christian Maeder

6:49 a.m.

Am 04.02.2011 11:49, schrieb Christian Maeder:

...

The disadvantage for just strings are possible spelling errors. With constants or constructors spelling errors are detected by the compiler (but you still can confuse constants having the same type).

Therefore just having type Method = ByteString is also less safe, because constants for methods and i.e. header names (if they are also just byte strings) can be mixed up without type errors. Better would be a newtype wrapper around byte strings (or just strings): newtype Method = M ByteString But I do not want to interfere with Michael Snoymann's compatibility issues for wai. Cheers Christian

Aristid Breitkreuz

2:37 p.m.

Christian, I incorporated your approach of defining the ADT, and Michael's suggestions into *tada* http-types 0.2.0 - http://hackage.haskell.org/package/http-types-0.2.0 Features: * StdMethod is an enumeration without OtherMethod constructor, containing only RFC 2616 standard HTTP methods. * parseMethod :: ByteString -> Either ByteString StdMethod (I think the type says all). * There are a few pre-defined Headers (headerAccept...) * urlEncode / urlDecode * Parsing and rendering of query strings (Query / SimpleQuery). I hope this is closer to what most people would consider a nice version. Aristid 2011/2/4 Christian Maeder

...

Am 04.02.2011 11:49, schrieb Christian Maeder:

...
The disadvantage for just strings are possible spelling errors. With constants or constructors spelling errors are detected by the compiler (but you still can confuse constants having the same type).

Therefore just having

type Method = ByteString

is also less safe, because constants for methods and i.e. header names (if they are also just byte strings) can be mixed up without type errors.

Better would be a newtype wrapper around byte strings (or just strings):

newtype Method = M ByteString

But I do not want to interfere with Michael Snoymann's compatibility issues for wai.

Cheers Christian

Aristid Breitkreuz

5 Feb 5 Feb

10:38 a.m.

http-types 0.3.0 contains a small, but breaking, change: old: renderMethod :: StdMethod -> ByteString new: renderStdMethod :: StdMethod -> ByteString ; renderMethod :: Either ByteString StdMethod -> ByteString Aristid 2011/2/4 Aristid Breitkreuz

...

Christian, I incorporated your approach of defining the ADT, and Michael's suggestions into

*tada*

http-types 0.2.0 - http://hackage.haskell.org/package/http-types-0.2.0

Features: * StdMethod is an enumeration without OtherMethod constructor, containing only RFC 2616 standard HTTP methods. * parseMethod :: ByteString -> Either ByteString StdMethod (I think the type says all). * There are a few pre-defined Headers (headerAccept...) * urlEncode / urlDecode * Parsing and rendering of query strings (Query / SimpleQuery).

I hope this is closer to what most people would consider a nice version.

Aristid

2011/2/4 Christian Maeder

Am 04.02.2011 11:49, schrieb Christian Maeder:

...
...
The disadvantage for just strings are possible spelling errors. With constants or constructors spelling errors are detected by the compiler (but you still can confuse constants having the same type).

Therefore just having

type Method = ByteString

is also less safe, because constants for methods and i.e. header names (if they are also just byte strings) can be mixed up without type errors.

Better would be a newtype wrapper around byte strings (or just strings):

newtype Method = M ByteString

But I do not want to interfere with Michael Snoymann's compatibility issues for wai.

Cheers Christian

Michael Snoyman

6 Feb 6 Feb

2:07 a.m.

It's looking very good. A few minor points: * urlEncode will only work for query-string encoding: there are different encoding rules depending on which part of the URL we're dealing with. For example, in the path info, a question mark is reserved IIRC. * The docs for StdMethod still refer to OtherMethod. * I would personally like to see parse/renderPathInfo (however you want to call it) in this package. Would you accept a patch? For that matter, if I see other functions that I think could logically be included here, would you accept a patch? * I hadn't thought of having the header* things generate a pair, I think it's a nice touch. Let's let the dust settle on this package, and on WAI, and then I'll likely start moving WAI and http-enumerator over to this. I appreciate the rename to CIByteString, it makes the transition easier. Michael On Sat, Feb 5, 2011 at 5:38 PM, Aristid Breitkreuz wrote:

...

http-types 0.3.0 contains a small, but breaking, change: old: renderMethod :: StdMethod -> ByteString new: renderStdMethod :: StdMethod -> ByteString ; renderMethod :: Either ByteString StdMethod -> ByteString

Aristid

2011/2/4 Aristid Breitkreuz

...
Christian, I incorporated your approach of defining the ADT, and Michael's suggestions into *tada* http-types 0.2.0 - http://hackage.haskell.org/package/http-types-0.2.0 Features: * StdMethod is an enumeration without OtherMethod constructor, containing only RFC 2616 standard HTTP methods. * parseMethod :: ByteString -> Either ByteString StdMethod (I think the type says all). * There are a few pre-defined Headers (headerAccept...) * urlEncode / urlDecode * Parsing and rendering of query strings (Query / SimpleQuery). I hope this is closer to what most people would consider a nice version.

Aristid

2011/2/4 Christian Maeder

...
Am 04.02.2011 11:49, schrieb Christian Maeder:

...
The disadvantage for just strings are possible spelling errors. With constants or constructors spelling errors are detected by the compiler (but you still can confuse constants having the same type).

Therefore just having

type Method = ByteString

is also less safe, because constants for methods and i.e. header names (if they are also just byte strings) can be mixed up without type errors.

Better would be a newtype wrapper around byte strings (or just strings):

newtype Method = M ByteString

But I do not want to interfere with Michael Snoymann's compatibility issues for wai.

Cheers Christian

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Aristid Breitkreuz

10:27 a.m.

2011/2/6 Michael Snoyman

...

It's looking very good. A few minor points:

* urlEncode will only work for query-string encoding: there are different encoding rules depending on which part of the URL we're dealing with. For example, in the path info, a question mark is reserved IIRC.

I implemented the rules as described in http://en.wikipedia.org/wiki/Percent-encoding Note that '?' (question mark) actually IS reserved and will be encoded. It's just that the initial '?' from the query string is never passed through urlEncode. There might be other cases in which we need different encoding rules, and I will gladly accept suggestions, or even better: patches.

...

* The docs for StdMethod still refer to OtherMethod.

Thanks for catching this. I will fix this and other documentation in the next release. * I would personally like to see parse/renderPathInfo (however you

...

want to call it) in this package. Would you accept a patch? For that matter, if I see other functions that I think could logically be included here, would you accept a patch?

How would {parse,render}PathInfo work? Yes, I'm glad to accept patches. The easiest method would probably to fork my repository on github.

...

* I hadn't thought of having the header* things generate a pair, I think it's a nice touch.

Let's let the dust settle on this package, and on WAI, and then I'll likely start moving WAI and http-enumerator over to this. I appreciate the rename to CIByteString, it makes the transition easier.

Looking forward to it! Aristid

5221

Age (days ago)

5224

Last active (days ago)

List overview

Download

13 comments

3 participants

participants (3)

Aristid Breitkreuz
Christian Maeder
Michael Snoyman