cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] Merging http_integration to Trunk

[Dean M. B. <mik...@gm...>]

Hi Glyn,

On Tue, Sep 16, 2008 at 2:39 AM, Glyn Matthews <gly...@gm...> wrote:
>
> 2008/9/15 Dean Michael Berris <mik...@gm...>
>>
>>
>> 1. There are any outstanding issues we need to address before I merge
>> to trunk and tag 0.3
>
> Not that I see.
>

Great. :)

>>
>> 2. There have been and updates to documentation that needs mention
>
> I haven't made any updates to the documentation.
>

Okay, I think I have to make some changes to the discussion regarding
the HTTP client. The documentation should reflect the new constructor
options and new method added to the HTTP Client.

>>
>> 3. There are any objections to the merge
>
> Not from me.
>

Thanks. :)

> If you need anything from me, let me know.

I will. Thanks again Glyn!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] Modern C++

[K. G. <kim...@gm...>]

Hi Dean,

On Mon, Sep 15, 2008 at 09:37, Dean Michael Berris
<mik...@gm...> wrote:
>
> If you had your own message tag (that's not the same message tag
> that's provided in the library) where you specialized the behavior of
> the actual message object(s) -- an example of a streaming/asynchronous
> message comes to mind -- allows you to either re-use the existing
> client implementation (basic_client<your_tag, 1, 0>) or extend the
> implementation such that you have tag-specific behavior (use futures,
> buffered asynchronous streams, etc.) without compromising existing
> usage of default-tagged implementations.

Right. so at the moment, most/all associated traits are just typedefs
(string_type, etc.), but given a more complex message/client, we could
add behaviors associated with the tag as well, without disturbing the
existing code.

> The bad part about blobs (or traits grouped together) is that it's
> hard to extend that design -- you cannot add new traits around tags
> and designs without running into the 'too many member' problem.

Yup, it makes sense. We can add or change functionality of the class
without modifying the class. Sweet.

>> 2) directives -- I don't see what benefit these added over member
>> functions on the message... Help?
>
> The directives can also be specialized by tags, so that you can make
> it do other things based on the tag. This is also built in with
> extensibility in mind.

Cool. I think I understand.

Thanks,
- Kim

Re: [cpp-netlib-devel] Merging http_integration to Trunk

[Glyn M. <gly...@gm...>]

Hi Dean,

2008/9/15 Dean Michael Berris <mik...@gm...>

> Hi Everyone,
>
> I'm currently in the process of setting up my OpenSolaris 2008.05
> Virtual Machine (using VirtualBox from Sun Microsystems) and in a
> while once I get it set up and updated to the latest, I should be able
> to merge http_integration and docs to trunk.
>
> Before I do so though, I'd like to ask if:
>
> 1. There are any outstanding issues we need to address before I merge
> to trunk and tag 0.3

Not that I see.


>
> 2. There have been and updates to documentation that needs mention

I haven't made any updates to the documentation.


>
> 3. There are any objections to the merge
>
Not from me.

If you need anything from me, let me know.
G

Re: [cpp-netlib-devel] mime (http integration)

[Dean M. B. <mik...@gm...>]

Hi Allister,

On Mon, Sep 15, 2008 at 4:07 PM, Allister Levi Sanchez
<all...@gm...> wrote:
>
>
> Sorry, I got too caught up in other things right now.

It's alright. It happens to the best of us. :)

> Also, I'm not yet
> sure if my implementation in mime.hpp is consistent with the your idea of
> how it's gonna be used.  Could you or anyone please have a good look at the
> code and see if it's handy enough to be used with the http library (and
> other foreseeable protocols that will be implemented)?

Can you give me (or everyone) an idea as to how you intend the library
to be used (in code, preferably as a set of unit tests) so that we can
continue to work on the library? :-)

> Also, I have to
> admit my grasp of modern C++ idioms and networking protocols is not that
> good (yet), so I would appreciate if someone could give me a good
> lecture/critique of my implementation.
>

If we had something like a reviewboard
(http://code.google.com/p/reviewboard/) installation then this would
be way easier.

Besides, it doesn't have to go modern C++ in the first drop -- we can
work on that as it goes along. :-)

Do you have concrete usage scenarios you'd like to first be able to
address which can be expressed in a simple unit test so that we can go
about writing it incrementally?

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] mime (http integration)

[Allister L. S. <all...@gm...>]

Hi Dean and everyone,

On Mon, Sep 15, 2008 at 7:14 AM, Dean Michael Berris <mik...@gm...
> wrote:

> Hi Allister,
>
> Any news on the branch/library?
>
> Have you got the chance to write the unit tests for the library yet? :D
>
> Looking forward to the code... ;-)
>

Sorry, I got too caught up in other things right now.  Also, I'm not yet
sure if my implementation in mime.hpp is consistent with the your idea of
how it's gonna be used.  Could you or anyone please have a good look at the
code and see if it's handy enough to be used with the http library (and
other foreseeable protocols that will be implemented)?  Also, I have to
admit my grasp of modern C++ idioms and networking protocols is not that
good (yet), so I would appreciate if someone could give me a good
lecture/critique of my implementation.

Cheers,
Allister

Re: [cpp-netlib-devel] Modern C++

[Dean M. B. <mik...@gm...>]

Hi Kim,

On Mon, Sep 15, 2008 at 3:23 PM, Kim Gräsman <kim...@gm...> wrote:
>
> I've noticed the cpp-netlib code base uses a couple of idioms that I
> don't really get:
>
> 1) tags -- I (think I) understand tag dispatching, but I don't see a
> clear-cut reason to use a tag with the basic_client, for example...?

Ok.

> Is it just something to group traits around?

No. :-)

The idea of being able to specialize implementations on traits is a
very big extensibility plus. Consider:

If you had your own message tag (that's not the same message tag
that's provided in the library) where you specialized the behavior of
the actual message object(s) -- an example of a streaming/asynchronous
message comes to mind -- allows you to either re-use the existing
client implementation (basic_client<your_tag, 1, 0>) or extend the
implementation such that you have tag-specific behavior (use futures,
buffered asynchronous streams, etc.) without compromising existing
usage of default-tagged implementations.

This is all kept in mind to enable seamless extension using templates. :-)

> I think I would have
> naively built a message_traits class, that exposed the respective
> typedefs, so I don't really see the benefit of the scattered traits
> structs. Except maybe for the fact that they _are_ scattered, so they
> can be specialized on a case-by-case basis?
>

The bad part about blobs (or traits grouped together) is that it's
hard to extend that design -- you cannot add new traits around tags
and designs without running into the 'too many member' problem.
Besides, it's also not good design to have 1+ nested types where you
only need to access 1.

> 2) directives -- I don't see what benefit these added over member
> functions on the message... Help?
>

This is to support the following syntax:

using namespace boost::network;
http::message msg;
msg << header("Header", "value")
  << header("AnotherHeader", "value")
  << body("The quick brown fox jumps over the lazy dog.");

The directives can also be specialized by tags, so that you can make
it do other things based on the tag. This is also built in with
extensibility in mind.

Using this approach, we get extensibility for free along with a
semantically consistent interface to the message framework.

> Thanks for any pointers,

HTH

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

[cpp-netlib-devel] Modern C++

[K. G. <kim...@gm...>]

Hello all,

Pardon the noise...

This project caught my interest partly because it uses modern C++
techniques, and I'm not practically familiar with them. I've read
quite a bit about the techniques, so I think I understand them at a
theoretical level, but I don't have an intuitive sense of what to
apply when.

I've noticed the cpp-netlib code base uses a couple of idioms that I
don't really get:

1) tags -- I (think I) understand tag dispatching, but I don't see a
clear-cut reason to use a tag with the basic_client, for example...?
Is it just something to group traits around? I think I would have
naively built a message_traits class, that exposed the respective
typedefs, so I don't really see the benefit of the scattered traits
structs. Except maybe for the fact that they _are_ scattered, so they
can be specialized on a case-by-case basis?

2) directives -- I don't see what benefit these added over member
functions on the message... Help?

Thanks for any pointers,
- Kim

Re: [cpp-netlib-devel] mime (http integration)

[Dean M. B. <mik...@gm...>]

Hi Allister,

Any news on the branch/library?

Have you got the chance to write the unit tests for the library yet? :D

Looking forward to the code... ;-)

On Wed, Sep 3, 2008 at 2:39 PM, Dean Michael Berris
<mik...@gm...> wrote:
> On Wed, Sep 3, 2008 at 2:24 PM, Allister Levi Sanchez
[snip]

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

[cpp-netlib-devel] Merging http_integration to Trunk

[Dean M. B. <mik...@gm...>]

Hi Everyone,

I'm currently in the process of setting up my OpenSolaris 2008.05
Virtual Machine (using VirtualBox from Sun Microsystems) and in a
while once I get it set up and updated to the latest, I should be able
to merge http_integration and docs to trunk.

Before I do so though, I'd like to ask if:

1. There are any outstanding issues we need to address before I merge
to trunk and tag 0.3
2. There have been and updates to documentation that needs mention
3. There are any objections to the merge

I'll rename the 'clear_cache()' method to 'clear_resolved_cache()'
before doing the merge -- and after a round of testing, I should be
able to merge with no hitches.

Let me know if you need anything specifically merged in before I release 0.3.

Have a good day everyone, and I hope to hear from you real soon. ;-)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[K. G. <kim...@gm...>]

Hi people,

On Thu, Sep 11, 2008 at 10:07, Allister Levi Sanchez
<all...@gm...> wrote:
>
>> I'm thinking that it should be simple to build a little header
>> dictionary that can parse the HTTP_ALL_HEADERS string, and use it from
>> all CGI scripts. That way, the headers are available similarly to
>> cgi.FieldStorage().headers, but in raw form.
>
> Hmmm, I think you're on to something interesting here...  Maybe that's
> better or more efficient or more elegant than having so many environment
> variables...  Looking forward to what you can cook up then :-)

I've committed rev 93 to http_integration, which uses this technique
to transport all headers from server to cgi script. I added
cgisupport.http_headers, which wraps this relative weirdness and
exposes the headers as a bona-fide dictionary.

Seems to be working...

> As you may know, a module is simply a *.py file.  To make it importable,
> simply put it in the same folder as the importing code or add the path to
> its containing folder to $PYTHONPATH.

Thanks! Currently cgisupport is only used from the cgi-bin dir, so I
placed it there. I think that's good enough,

Let me know if there are problems on non-Windows platforms.

Cheers,
- Kim

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[Allister L. S. <all...@gm...>]

Hi Kim,

I'm thinking that it should be simple to build a little header
> dictionary that can parse the HTTP_ALL_HEADERS string, and use it from
> all CGI scripts. That way, the headers are available similarly to
> cgi.FieldStorage().headers, but in raw form.


Hmmm, I think you're on to something interesting here...  Maybe that's
better or more efficient or more elegant than having so many environment
variables...  Looking forward to what you can cook up then :-)


> That said, my Python-Fu is not so strong, either, so I'm not sure
> what's involved in making a module that's importable from other
> scripts...?


As you may know, a module is simply a *.py file.  To make it importable,
simply put it in the same folder as the importing code or add the path to
its containing folder to $PYTHONPATH.


> > Also, I think it's better that we expose the command handles do_GET,
> > do_POST, do_DELETE, etc. (as was the case in revision 90 of
> > http_test_server.py) at the level of the HttpTestHandler class as we are
> > most likely to overload them in the future to fully comply with RFC 2616.
>
> Ah, I just saw that they all delegated to the base, and so I figured
> they were redundant. To me it seems better to just override when
> necessary, but I don't have a strong opinion either way.
>

Okay, we'll cross the bridge when we get there :-)  We'll add those
functions when needed -- although I just thought someone out there might be
interested (tempted) in writing the necessary code once he/she sees those
poor unimplemented functions :-)

Cheers,
Allister

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[K. G. <kim...@gm...>]

Hi Allister,

On Wed, Sep 10, 2008 at 17:34, Allister Levi Sanchez
<all...@gm...> wrote:
>
> I think it'd be better to parse the standard headers first in the handler
> class (HttpTestHandler), to make it easier for people to write scripts for
> various tests, and not have to duplicate code for the standard HTTP headers.
>  Besides, we only use HTTP_ALL_HEADERS for custom headers.  We can then
> write different CGI scripts for tests using different custom headers.  So
> having both could be beneficial.

I'm thinking that it should be simple to build a little header
dictionary that can parse the HTTP_ALL_HEADERS string, and use it from
all CGI scripts. That way, the headers are available similarly to
cgi.FieldStorage().headers, but in raw form.

That said, my Python-Fu is not so strong, either, so I'm not sure
what's involved in making a module that's importable from other
scripts...?

> Also, I think it's better that we expose the command handles do_GET,
> do_POST, do_DELETE, etc. (as was the case in revision 90 of
> http_test_server.py) at the level of the HttpTestHandler class as we are
> most likely to overload them in the future to fully comply with RFC 2616.

Ah, I just saw that they all delegated to the base, and so I figured
they were redundant. To me it seems better to just override when
necessary, but I don't have a strong opinion either way.

- Kim

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[Allister L. S. <all...@gm...>]

Hi Kim,
I think it'd be better to parse the standard headers first in the handler
class (HttpTestHandler), to make it easier for people to write scripts for
various tests, and not have to duplicate code for the standard HTTP headers.
 Besides, we only use HTTP_ALL_HEADERS for custom headers.  We can then
write different CGI scripts for tests using different custom headers.  So
having both could be beneficial.

Also, I think it's better that we expose the command handles do_GET,
do_POST, do_DELETE, etc. (as was the case in revision 90 of
http_test_server.py) at the level of the HttpTestHandler class as we are
most likely to overload them in the future to fully comply with RFC 2616.

That said though, I would love to hear the thoughts of the others on this.

Cheers,
Allister

On Wed, Sep 10, 2008 at 4:42 PM, Kim Gräsman <kim...@gm...> wrote:

> Hi Allister,
>
> It wasn't quite as easy, but almost. I've committed a version that
> forwards all headers, newline-separated, as a string in
> HTTP_ALL_HEADERS.
>
> Not sure if it was a good idea, but I replaced all your named header
> handling with this simple, raw, forwarding. Maybe we should have both?
> Not sure if it makes sense, though.
>
> All tests seem to run anyway, at least on Windows.
>
> Thanks,
> - Kim
>

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[K. G. <kim...@gm...>]

Hi Allister,

On Wed, Sep 10, 2008 at 09:07, Allister Levi Sanchez
<all...@gm...> wrote:
> Something like this in
> http_test_server.py:
> all_headers = ',--aUniqueSeparator--,'.join(self.headers)
> os.environ['HTTP_ALL_HEADERS'] = all_headers
> and in the CGI script, we can easily recover it:
> list_of_all_headers =
> os.environ.get('HTTP_ALL_HEADERS','').split(',--aUniqueSeparator--,')
> There you have it.  I'll commit it after work -- or you could commit it
> yourself ;-)

It wasn't quite as easy, but almost. I've committed a version that
forwards all headers, newline-separated, as a string in
HTTP_ALL_HEADERS.

Not sure if it was a good idea, but I replaced all your named header
handling with this simple, raw, forwarding. Maybe we should have both?
Not sure if it makes sense, though.

All tests seem to run anyway, at least on Windows.

Thanks,
- Kim

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[K. G. <kim...@gm...>]

Hi Allister,

On Wed, Sep 10, 2008 at 09:07, Allister Levi Sanchez
<all...@gm...> wrote:
>
> If we look deep at the code (see $PYTHON_HOME/Lib/rfc822.py), self.headers
> is simply a list.  One can simply concatenate the elements of a list (with a
> really unique separator) and add it into os.environ.  Something like this in
> http_test_server.py:
> all_headers = ',--aUniqueSeparator--,'.join(self.headers)
> os.environ['HTTP_ALL_HEADERS'] = all_headers
> and in the CGI script, we can easily recover it:
> list_of_all_headers =
> os.environ.get('HTTP_ALL_HEADERS','').split(',--aUniqueSeparator--,')
> There you have it.  I'll commit it after work -- or you could commit it
> yourself ;-)

Sweet!

- Kim

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[Allister L. S. <all...@gm...>]

Hi Kim,

On Wed, Sep 10, 2008 at 8:12 AM, Kim Gräsman <kim...@gm...> wrote:

> Cool, thanks!


You're welcome :-)


> I had trouble with custom headers, though, and it looks like they're
> still hard to pull through?
>
> I'm thinking about maybe base64-encoding all of self.headers and
> putting it into an env var as-is, and then decoding it on the CGI
> side. That should do the trick...


If we look deep at the code (see $PYTHON_HOME/Lib/rfc822.py), self.headers
is simply a list.  One can simply concatenate the elements of a list (with a
really unique separator) and add it into os.environ.  Something like this in
http_test_server.py:

all_headers = ',--aUniqueSeparator--,'.join(self.headers)
os.environ['HTTP_ALL_HEADERS'] = all_headers

and in the CGI script, we can easily recover it:

list_of_all_headers =
os.environ.get('HTTP_ALL_HEADERS','').split(',--aUniqueSeparator--,')

There you have it.  I'll commit it after work -- or you could commit it
yourself ;-)

Cheers,
Allister

Re: [cpp-netlib-devel] Warning policy

[K. G. <kim...@gm...>]

Hi Dean,

On Wed, Sep 10, 2008 at 07:27, Dean Michael Berris
<mik...@gm...> wrote:
>
> This is only in the tests right? I'm thinking since we're header only
> we should let the users define that instead. ;-)

Yeah, it's only the tests that need an actual Jamfile, the headers are
pretty self-sufficient :)

- Kim

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[K. G. <kim...@gm...>]

Hi Allister,

On Wed, Sep 10, 2008 at 00:05, Allister Levi Sanchez
<all...@gm...> wrote:
>
> The new server is in server/http_test_server.py and it is now called from
> server/http_test_server.cpp.  In server/cgi-bin/requestinfo.py, I also added
> sample code on how to get these headers -- although it should be pretty
> obvious ;-)

Cool, thanks!

I had trouble with custom headers, though, and it looks like they're
still hard to pull through?

I'm thinking about maybe base64-encoding all of self.headers and
putting it into an env var as-is, and then decoding it on the CGI
side. That should do the trick...

- Kim

Re: [cpp-netlib-devel] Warning policy

[Dean M. B. <mik...@gm...>]

On Wed, Sep 10, 2008 at 1:26 PM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> On Wed, Sep 10, 2008 at 05:27, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> I don't mind. If you can do:
>>
>>  <toolset>msvc:<define>_SCL_SECURE
>>
>> That would be nice.
>
> It's _SCL_SECURE_NO_WARNINGS, but yes, otherwise added! Committed in
> the http_integration branch.
>

This is only in the tests right? I'm thinking since we're header only
we should let the users define that instead. ;-)

Thanks Kim! :)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] Warning policy

[K. G. <kim...@gm...>]

Hi Dean,

On Wed, Sep 10, 2008 at 05:27, Dean Michael Berris
<mik...@gm...> wrote:
>
> I don't mind. If you can do:
>
>  <toolset>msvc:<define>_SCL_SECURE
>
> That would be nice.

It's _SCL_SECURE_NO_WARNINGS, but yes, otherwise added! Committed in
the http_integration branch.

Thanks,
- Kim

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[Dean M. B. <mik...@gm...>]

Hi Allister!

On Wed, Sep 10, 2008 at 6:05 AM, Allister Levi Sanchez
<all...@gm...> wrote:
> Hi folks,
>
> I've created a new python server that provides all the headers (as defined
> in RFC 2616).  I created a handler based on CGIHTTPRequestHandler (which
> already provides HEAD, POST, and GET).  I've also placed methods for PUT,
> DELETE, TRACE, etc., although for the moment all they do is return a 405
> error.  Once I get to reading the HTTP specs, I might have a better idea on
> how to implement them.  But if you know what to do, go ahead and try your
> python kungfu on the methods I've prepared. :-)
>
> The new server is in server/http_test_server.py and it is now called from
> server/http_test_server.cpp.  In server/cgi-bin/requestinfo.py, I also added
> sample code on how to get these headers -- although it should be pretty
> obvious ;-)
>

Sweet! Thanks. :-D

Would love to see more tests in localhost_test that take advantage of
this new testing server. :-D

> Cheers,
> Allister
>

Thanks Allister! :-)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] Warning policy

[Dean M. B. <mik...@gm...>]

Hi Kim,

On Wed, Sep 10, 2008 at 1:12 AM, Kim Gräsman <kim...@gm...> wrote:
> Hello,
>
> When building the tests on Windows using VC9, I get a couple of secure
> SCL warnings on std::copy.
>
> Does anybody mind if I disable those warnings via a define in the
> Jamfile? I'm not sure how Boost generally does it, or if there even is
> a policy...
>

I don't mind. If you can do:

  <toolset>msvc:<define>_SCL_SECURE

That would be nice.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[Allister L. S. <all...@gm...>]

Hi folks,

I've created a new python server that provides all the headers (as defined
in RFC 2616).  I created a handler based on CGIHTTPRequestHandler (which
already provides HEAD, POST, and GET).  I've also placed methods for PUT,
DELETE, TRACE, etc., although for the moment all they do is return a 405
error.  Once I get to reading the HTTP specs, I might have a better idea on
how to implement them.  But if you know what to do, go ahead and try your
python kungfu on the methods I've prepared. :-)

The new server is in server/http_test_server.py and it is now called from
server/http_test_server.cpp.  In server/cgi-bin/requestinfo.py, I also added
sample code on how to get these headers -- although it should be pretty
obvious ;-)

Cheers,
Allister

On Tue, Sep 9, 2008 at 1:29 PM, Kim Gräsman <kim...@gm...> wrote:

> Hi Dean,
>
> On Tue, Sep 9, 2008 at 11:22, Dean Michael Berris
> <mik...@gm...> wrote:
> >> So, as far as I can see there's no reliable way to dump all request
> >> headers to the response from a CGI script, via the Python server. The
> >> ones that make it through are listed in the run_cgi method in Python's
> >> CGIHTTPServer.py. Content-Length and Content-Type are among them, so I
> >> thought I had it working for a while :-/
> >
> > Is there no way to define which headers (or if all headers) should be
> preserved?
>
> Not as far as I can tell... I think maybe this problem is part of the
> CGI concept as well; since it uses environment vars to pass on
> selected headers, there's a risk that custom headers overwrite env
> vars that the shell depends upon. Unless you jump through hoops to
> escape them, etc, or encode all headers into one long string, somehow.
> But then it's no longer CGI per se.
>
> > That should be alright... We may find a better way to go about things
> > if we write our own HTTPServer extension which does what we want
> > instead of relying on the CGIHTTPServer that Python defines.
> >
> > I don't have enough Python kung fu to be able to pull it off yet
> > though so if you find other ways, I'm all ears. ;-)
>
> Me neither, I'm just guessing my way ahead :)
>
> We could potentially derive from one of the requesthandlers and
> implement our own, but then we'd have to figure out a good way to get
> all the request data from the web server to the handler script,
> essentially reinventing CGI. Unless we want to do it all in one
> mega-script, in-process.
>
> Oh well...
>
> - Kim
>
>

[cpp-netlib-devel] Warning policy

[K. G. <kim...@gm...>]

Hello,

When building the tests on Windows using VC9, I get a couple of secure
SCL warnings on std::copy.

Does anybody mind if I disable those warnings via a define in the
Jamfile? I'm not sure how Boost generally does it, or if there even is
a policy...

Thanks,
- Kim

Re: [cpp-netlib-devel] [python] Getting HTTP Headers

[K. G. <kim...@gm...>]

Hi Dean,

On Tue, Sep 9, 2008 at 11:22, Dean Michael Berris
<mik...@gm...> wrote:
>> So, as far as I can see there's no reliable way to dump all request
>> headers to the response from a CGI script, via the Python server. The
>> ones that make it through are listed in the run_cgi method in Python's
>> CGIHTTPServer.py. Content-Length and Content-Type are among them, so I
>> thought I had it working for a while :-/
>
> Is there no way to define which headers (or if all headers) should be preserved?

Not as far as I can tell... I think maybe this problem is part of the
CGI concept as well; since it uses environment vars to pass on
selected headers, there's a risk that custom headers overwrite env
vars that the shell depends upon. Unless you jump through hoops to
escape them, etc, or encode all headers into one long string, somehow.
But then it's no longer CGI per se.

> That should be alright... We may find a better way to go about things
> if we write our own HTTPServer extension which does what we want
> instead of relying on the CGIHTTPServer that Python defines.
>
> I don't have enough Python kung fu to be able to pull it off yet
> though so if you find other ways, I'm all ears. ;-)

Me neither, I'm just guessing my way ahead :)

We could potentially derive from one of the requesthandlers and
implement our own, but then we'd have to figure out a good way to get
all the request data from the web server to the handler script,
essentially reinventing CGI. Unless we want to do it all in one
mega-script, in-process.

Oh well...

- Kim