www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - http libraries for d

reply jicman <jicman_member pathlink.com> writes:
Any HTTP libraries for d out there?  Or has anyone done any heavy http
programming with d?

thanks.
Feb 10 2005
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
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
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
parent reply Kris <Kris_member pathlink.com> writes:
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
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
parent Kris <Kris_member pathlink.com> writes:
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