digitalmars.D - http libraries for d
- jicman (3/3) Feb 10 2005 Any HTTP libraries for d out there? Or has anyone done any heavy http
- John Reimer (6/12) Feb 10 2005 I'm not sure what you're looking for exactly. Perhaps have a look at
- Matthew (3/7) Feb 10 2005 Check out Mango. (On dsource.org)
- Unknown W. Brackets (4/18) Feb 10 2005 Correct me if I'm wrong, but last time I looked at its source, it used
- Kris (8/26) Feb 10 2005 It doesn't do 'chunking', at this point. It'd be great if you, or anyone...
- Unknown W. Brackets (30/39) Feb 11 2005 I may indeed look into it, if I have time. However, if you don't
- Kris (3/42) Feb 11 2005 Too true. T'was just a matter of time. I'll roll back the version-tag.
Any HTTP libraries for d out there? Or has anyone done any heavy http programming with d? thanks.
Feb 10 2005
jicman wrote:Any HTTP libraries for d out there? Or has anyone done any heavy http programming with d? thanks.I'm not sure what you're looking for exactly. Perhaps have a look at the Mango library at yonder dsource.org/projects/mango. Server side programming stuff. Currently one of D's best available libs if you like OO style programming. - John R.
Feb 10 2005
Check out Mango. (On dsource.org) "jicman" <jicman_member pathlink.com> wrote in message news:cugltj$2jf$1 digitaldaemon.com...Any HTTP libraries for d out there? Or has anyone done any heavy http programming with d? thanks.
Feb 10 2005
Correct me if I'm wrong, but last time I looked at its source, it used HTTP/1.1 but I didn't see any handling for the chunked (default for 1.1) encoding. Has it been well tested? -[Unknown]Check out Mango. (On dsource.org) "jicman" <jicman_member pathlink.com> wrote in message news:cugltj$2jf$1 digitaldaemon.com...Any HTTP libraries for d out there? Or has anyone done any heavy http programming with d? thanks.
Feb 10 2005
It doesn't do 'chunking', at this point. It'd be great if you, or anyone, were to add that :) It's also in need of an SSL wrapper, if anyone is up for that? As for testing, it's been beaten up pretty well for the simple requests. The server was built primarily for Servlet support, so that's where the focus has been so far. Having said that, it's flexible and simple enough to extend as necessary. - Kris In article <cuhien$tbo$2 digitaldaemon.com>, Unknown W. Brackets says...Correct me if I'm wrong, but last time I looked at its source, it used HTTP/1.1 but I didn't see any handling for the chunked (default for 1.1) encoding. Has it been well tested? -[Unknown]Check out Mango. (On dsource.org) "jicman" <jicman_member pathlink.com> wrote in message news:cugltj$2jf$1 digitaldaemon.com...Any HTTP libraries for d out there? Or has anyone done any heavy http programming with d? thanks.
Feb 10 2005
I may indeed look into it, if I have time. However, if you don't support chunked, you should REALLY use HTTP/1.0 instead of 1.1. Still sending the Host header shouldn't be a problem, but the transfer might look like this: 254 (254 bytes) 324 (324 bytes) 15 (15 bytes) 0 Using HTTP/1.0 indicates you do not support this functionality. This was, along with Host and Connection, the major change made in 1.1. The specification clearly uses MUST for implementing chunked if you want to send HTTP/1.1. I quote (RFC 2068): All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer coding... And where must means: MUST This word or the adjective "required" means that the item is an absolute requirement of the specification. Implementing chunked wouldn't be too hard, but to really implement a full HTTP client, it should send a user-agent (some dumb servers will 500 otherwise) and do Content-Encoding properly (compression.) It should also implement base64, quoted-printable, etc just in case they are used (since they can be by the spec/rfc but generally never are.) I've never dealt with the technical side of SSL connections and would be of little help there. -[Unknown]It doesn't do 'chunking', at this point. It'd be great if you, or anyone, were to add that :) It's also in need of an SSL wrapper, if anyone is up for that? As for testing, it's been beaten up pretty well for the simple requests. The server was built primarily for Servlet support, so that's where the focus has been so far. Having said that, it's flexible and simple enough to extend as necessary. - Kris
Feb 11 2005
Too true. T'was just a matter of time. I'll roll back the version-tag. - Kris In article <cuhqmr$1a4f$1 digitaldaemon.com>, Unknown W. Brackets says...I may indeed look into it, if I have time. However, if you don't support chunked, you should REALLY use HTTP/1.0 instead of 1.1. Still sending the Host header shouldn't be a problem, but the transfer might look like this: 254 (254 bytes) 324 (324 bytes) 15 (15 bytes) 0 Using HTTP/1.0 indicates you do not support this functionality. This was, along with Host and Connection, the major change made in 1.1. The specification clearly uses MUST for implementing chunked if you want to send HTTP/1.1. I quote (RFC 2068): All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer coding... And where must means: MUST This word or the adjective "required" means that the item is an absolute requirement of the specification. Implementing chunked wouldn't be too hard, but to really implement a full HTTP client, it should send a user-agent (some dumb servers will 500 otherwise) and do Content-Encoding properly (compression.) It should also implement base64, quoted-printable, etc just in case they are used (since they can be by the spec/rfc but generally never are.) I've never dealt with the technical side of SSL connections and would be of little help there. -[Unknown]It doesn't do 'chunking', at this point. It'd be great if you, or anyone, were to add that :) It's also in need of an SSL wrapper, if anyone is up for that? As for testing, it's been beaten up pretty well for the simple requests. The server was built primarily for Servlet support, so that's where the focus has been so far. Having said that, it's flexible and simple enough to extend as necessary. - Kris
Feb 11 2005