Any HTTP libraries for d out there?  Or has anyone done any heavy http programming with d?

thanks.

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.

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.
>
> 

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.
>>
>>
> 
> 
> 

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.
>>>
>>>
>> 
>> 
>> 

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

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