April 2014 - web-devel

http2
by Kazu Yamamoto 21 Nov '14

21 Nov '14

Hi guys, I would like to announce the first release of the http2 package. http://hackage.haskell.org/package/http2 This package tries to implement the coming HTTP/2.0. HTTP/2.0 is being standardized in two internet-drafts: http://tools.ietf.org/html/draft-ietf-httpbis-http2-09 http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-05 The current version of the http2 library implements the latter (called HPACK) only at this moment. I would like to make this library so that other HTTP libraries can use when supporting HTTP/2.0. Feedback is welcome. --Kazu

7 15

ANN: uhttpc - Minimal HTTP client library optimized for benchmarking
by Herbert Valerio Riedel 30 Apr '14

30 Apr '14

Hello web-devel, (sorry if you get this twice, I originally sent this from an unsubscribed email address) Even though I already announced this on reddit[1], I was reminded by one of the comments this special-interest-group list exists, and therefore I'd like to point your attention to http://hackage.haskell.org/package/uhttpc which (as was pointed out by one reddit commenter) can be regarded as the client-side of acme-http. I've been able to get comparable measurements to what weighttp and ab reports against HTTP servers such as nginx, but I've noticed some sub-optimal results when using only a single kept-alive connection. For instance, on my i7-3770 Linux desktop against an nginx server I get: ,---- | $ uhttpc-bench -n 200000 -t1 -c2 -k http://localhost/ | uhttpc-bench - a Haskell-based ab/weighttp-style webserver benchmarking tool | | starting benchmark... | finished in 15.024069 seconds, 200000 reqs (1 conns), 13312.0 req/s received | status codes: 200000 HTTP-200 | data received: 11153.977 KiB/s, 171600000 bytes total (49200000 bytes http + 122400000 bytes content) | rtt min/avg/max = 0.038/0.074/9.928 ms `---- vs. ,---- | $ uhttpc-bench -n 200000 -t1 -c2 -k http://localhost/ | uhttpc-bench - a Haskell-based ab/weighttp-style webserver benchmarking tool | | starting benchmark... | finished in 4.849609 seconds, 200000 reqs (2 conns), 41240.4 req/s received | status codes: 200000 HTTP-200 | data received: 34554.976 KiB/s, 171600000 bytes total (49200000 bytes http + 122400000 bytes content) | rtt min/avg/max = 0.031/0.048/7.207 ms `---- Whereas running `weighttp` with -c1 vs -c2 gives a linear 1x factor scaling of 20k req/s vs 40k req/s (as opposed to the 1.5x factor scaling of uhttpc-bench between -c1 and -c2) Therefore, uhttpc-bench is significantly worse than weighttp when using only a single connection. I can't explain that yet. [1]: http://www.reddit.com/r/haskell/comments/23yuvs/%C2%B5http_lowlevel_http_cl…

2 1

Re: [web-devel] XSS vs charset
by Michael Snoyman 03 Apr '14

03 Apr '14

On Wed, Apr 2, 2014 at 9:08 AM, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: > Hi Michael, > > Thank you for your reply. > > > I suppose theoretically you could be talking about a situation where > Mighty > > is hosting a CGI application that receives user data and produces a > static > > HTML file as a result. > > Yes. Also I'm thinking about Yesod. > > Yesod has more of a focus on dynamic content, and in those cases, we *do* already set charset=utf8[1]. Where this would affect Yesod is in yesod-static, in which case the same logic I've applied to Mighty would apply: users should not be able to affect the content of static files under normal circumstances, so the security concern is pretty remote. [1] https://github.com/yesodweb/yesod/blob/master/yesod-core/Yesod/Core/Content… > > But it > > could be worked around by the CGI application using <meta charset=...> > > instead. > > Yes. Is this rarely used in Yesod? > > Yes. Dynamic responses don't normally go via static file serving at all. In WAI terms, we always end up with a ResponseBuilder, not a ResponseFile, for dynamic content. > > So that comes to the question: is it safe for Mighty, mime-types, etc, to > > require that all HTML files are stored as UTF-8? I'd say, as long as > > there's a way for a user to override that if necessary, it sounds good to > > me. mime-types does provide such a capability, so I'd be in favor of > > tweaking its textual types to include explicit charset information. > > Probably I was too sensitive. Based on your discussion, it is > safer/better for Mighty not to hard-code charset. > > To be clear, besides the security concerns, there is *definitely* a usability advantage in specifying charsets explicitly, in that the browser doesn't need to use defaults or guessing[2]. This just comes down to a numbers game: is it more likely that a browser will mis-guess the character encoding of UTF8 data, or that someone running Mighty will provide non-UTF8 data? One other point in the favor of specifying encoding type is that serving of a file will *reliably* fail. Without a charset, some browsers may guess the wrong character encoding while others won't, which makes it difficult to debug. If you *always* serve with charset=utf8 and that turns out to be wrong, you'll find out quickly and reliably. [2] http://en.wikipedia.org/wiki/Charset_detection

2 3

Re: [web-devel] XSS vs charset
by Michael Snoyman 02 Apr '14

02 Apr '14

Forgot to CC the list. On Wed, Apr 2, 2014 at 8:51 AM, Michael Snoyman <michael(a)snoyman.com> wrote: > I'm not sure if Mighty is really vulnerable to this attack. IIUC, you're > worried about a static file receiving some compromised data from a user > which includes a UTF-7 sequence. However, Mighty is only serving static > data files (as opposed to generating HTML from a database query or > something), so if a user is able to compromise those already, it sounds > like *nothing* you can do would prevent an attack. > > I suppose theoretically you could be talking about a situation where > Mighty is hosting a CGI application that receives user data and produces a > static HTML file as a result. In that case, you would be open to an attack. > But it could be worked around by the CGI application using <meta > charset=...> instead. > > Putting aside the question of this specific attack for the moment, what > would be the advantages and disadvantages of forcing charset=utf-8? > > * Advantage: if the data is actually UTF-8, the browser will always treat > it as such. Without such a specification, a browser is free to guess at > some other character encoding. > * Disadvantage: if the data isn't actually UTF-8, then the browser will > have no ability to try to guess the correct encoding instead. > > So that comes to the question: is it safe for Mighty, mime-types, etc, to > require that all HTML files are stored as UTF-8? I'd say, as long as > there's a way for a user to override that if necessary, it sounds good to > me. mime-types does provide such a capability, so I'd be in favor of > tweaking its textual types to include explicit charset information. > > > On Wed, Apr 2, 2014 at 8:02 AM, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: > >> Hi all, >> >> I heard that if an HTTP server does not specify charset for text/html >> in HTTP responses, XSS would be possible: >> >> http://openmya.hacker.jp/hasegawa/security/utf7cs.html >> >> I would like to change Mighty to specify charset=UTF-8. Before that, I >> would like to discuss some items on this ML. >> >> - Can we assume that recent contents are written in UTF-8? >> For Japanese community, the answer is probably YES. >> - Which components should spcify charset=UTF-8? >> The mime-types package? >> >> --Kazu >> _______________________________________________ >> web-devel mailing list >> web-devel(a)haskell.org >> http://www.haskell.org/mailman/listinfo/web-devel >> > >

1 0

XSS vs charset
by Kazu Yamamoto 02 Apr '14

02 Apr '14

Hi all, I heard that if an HTTP server does not specify charset for text/html in HTTP responses, XSS would be possible: http://openmya.hacker.jp/hasegawa/security/utf7cs.html I would like to change Mighty to specify charset=UTF-8. Before that, I would like to discuss some items on this ML. - Can we assume that recent contents are written in UTF-8? For Japanese community, the answer is probably YES. - Which components should spcify charset=UTF-8? The mime-types package? --Kazu

1 0