Menu
▾
▴
cpp-netlib-devel — Developers Mailing List
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(52) |
Jun
(30) |
Jul
(17) |
Aug
(9) |
Sep
(4) |
Oct
(7) |
Nov
(11) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(37) |
Apr
(28) |
May
(15) |
Jun
(28) |
Jul
(7) |
Aug
(125) |
Sep
(116) |
Oct
(85) |
Nov
(14) |
Dec
(6) |
| 2009 |
Jan
(11) |
Feb
(4) |
Mar
(5) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(4) |
Aug
(40) |
Sep
(1) |
Oct
(19) |
Nov
(43) |
Dec
(45) |
| 2010 |
Jan
(76) |
Feb
(95) |
Mar
(3) |
Apr
(23) |
May
(39) |
Jun
(54) |
Jul
(6) |
Aug
(13) |
Sep
(12) |
Oct
(59) |
Nov
(53) |
Dec
(43) |
| 2011 |
Jan
(43) |
Feb
(44) |
Mar
(25) |
Apr
(23) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Dean M. B. <mik...@gm...> - 2008-09-09 09:22:16
|
On Tue, Sep 9, 2008 at 3:40 PM, Kim Gräsman <kim...@gm...> wrote: > > On Mon, Sep 8, 2008 at 22:12, Kim Gräsman <kim...@gm...> wrote: >> >> On Mon, Sep 8, 2008 at 14:58, Divye Kapoor <div...@gm...> wrote: >>>> >>>> Tab/space separated values work -- they can easily be parsed through >>>> std::ostringstream's -- as well as doing a '\n' delimited lines for >>>> pseudo-CSV. >>> >>> Ok. >> >> I'm currently playing with a HTTP header-style format to echo headers >> for the post tests. >> >> I have a new post_echo_headers.py, that emits the request headers on >> the canonical "name: value\n" form. It gets harder if you want to >> combine headers and other data on the same page, though... > > I've looked into this more closely, and it appears that only selected > headers make it through to the CGI scripts. > > 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? > Grr. 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. ;-) Thanks for looking into this! :-D -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-09 07:40:33
|
Hi guys, On Mon, Sep 8, 2008 at 22:12, Kim Gräsman <kim...@gm...> wrote: > > On Mon, Sep 8, 2008 at 14:58, Divye Kapoor <div...@gm...> wrote: >>> >>> Tab/space separated values work -- they can easily be parsed through >>> std::ostringstream's -- as well as doing a '\n' delimited lines for >>> pseudo-CSV. >> >> Ok. > > I'm currently playing with a HTTP header-style format to echo headers > for the post tests. > > I have a new post_echo_headers.py, that emits the request headers on > the canonical "name: value\n" form. It gets harder if you want to > combine headers and other data on the same page, though... I've looked into this more closely, and it appears that only selected headers make it through to the CGI scripts. 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 :-/ Grr. - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-09-09 04:15:24
|
On Mon, Sep 8, 2008 at 9:50 PM, Divye Kapoor <div...@gm...> wrote: > Hello Dean, > > On Mon, Sep 8, 2008 at 11:21 AM, Dean Michael Berris > <mik...@gm...> wrote: >> >> A new member function 'clear_cached()' has been added to clear the >> resolved endpoint cache. >> > On a point of clarity, shouldn't that function be renamed to > clear_resolved_cache()? clear_cached() doesn't specify what cache is being > cleared. > Ah, yes. ;-) I wasn't looking into adding caching to the client yet -- and I was thinking it may be implied that the only thing cached are the resolved endpoints. I'll think about it before we tag for release 0.3. clear_resolved_cache() is a little long. Any other names? -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Dean M. B. <mik...@gm...> - 2008-09-09 04:13:30
|
On Mon, Sep 8, 2008 at 9:39 PM, Divye Kapoor <div...@gm...> wrote: > Hi Dean, > > On Mon, Sep 8, 2008 at 10:58 AM, Dean Michael Berris >> >> Can you write something that will induce this behavior without having >> to revert the version of requestinfo.py? > > I investigated the issue and it was because I was using an older version of > http::client. The issue seems resolved in the newer versions of > http::client. I guess I reverted one file too many. Sorry for the trouble. > Whew! That scared me just a little. ;-) Thanks for looking into it! :-) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-08 20:12:35
|
Dean, Divye, On Mon, Sep 8, 2008 at 14:58, Divye Kapoor <div...@gm...> wrote: >> >> Tab/space separated values work -- they can easily be parsed through >> std::ostringstream's -- as well as doing a '\n' delimited lines for >> pseudo-CSV. > > Ok. I'm currently playing with a HTTP header-style format to echo headers for the post tests. I have a new post_echo_headers.py, that emits the request headers on the canonical "name: value\n" form. It gets harder if you want to combine headers and other data on the same page, though... Maybe we can re-group once we find something that works for everybody? - Kim |
|
From: Divye K. <div...@gm...> - 2008-09-08 13:50:24
|
Hello Dean, On Mon, Sep 8, 2008 at 11:21 AM, Dean Michael Berris <mik...@gm... > wrote: > > A new member function 'clear_cached()' has been added to clear the > resolved endpoint cache. > > On a point of clarity, shouldn't that function be renamed to clear_resolved_cache()? clear_cached() doesn't specify what cache is being cleared. Divye -- An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup. H. L. Mencken (1880 - 1956) My official web site: http://people.iitr.ernet.in/shp/061305/ Webmaster: http://www.drkapoorsclinic.com Blog: http://divyekapoor.blogspot.com |
|
From: Divye K. <div...@gm...> - 2008-09-08 13:39:31
|
Hi Dean, On Mon, Sep 8, 2008 at 10:58 AM, Dean Michael Berris <mik...@gm... > wrote: > Hi Diyve, > > > Hmmm... I don't do getline() anymore, except from getting the headers, > which should throw if the server has already closed the connection > (connection reset). > > Can you write something that will induce this behavior without having > to revert the version of requestinfo.py? > I investigated the issue and it was because I was using an older version of http::client. The issue seems resolved in the newer versions of http::client. I guess I reverted one file too many. Sorry for the trouble. Divye -- An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup. H. L. Mencken (1880 - 1956) My official web site: http://people.iitr.ernet.in/shp/061305/ Webmaster: http://www.drkapoorsclinic.com Blog: http://divyekapoor.blogspot.com |
|
From: Divye K. <div...@gm...> - 2008-09-08 12:58:48
|
Hi Dean, On Mon, Sep 8, 2008 at 10:55 AM, Dean Michael Berris <mik...@gm... > wrote: > Hi Divye, > > When you say "there are a couple of bugs in the library", which > library are you referring to? > The python CGI library. > > And what exactly is the bug? A simple get request sets the content-type header to be application/x-www-form-urlencoded. This is an issue with the Python CGI library. Other than this minor bug, I haven't found any major issues with the code and I don't think any of the tests break. > > > I'm thinking of refactoring the entire file to make parsing of the > response > > easy. > > What would be the ideal response from the CGI script? CSV, XML or > something > > else? > > Currently, the response is rather kludgy to parse. > > > > Tab/space separated values work -- they can easily be parsed through > std::ostringstream's -- as well as doing a '\n' delimited lines for > pseudo-CSV. > Ok. > > > Comments would be helpful. > > HTH > Sure did. > > (BTW, I'll take a look at your code to see if anything breaks in > cpp-netlib) > Sure. Divye -- An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup. H. L. Mencken (1880 - 1956) My official web site: http://people.iitr.ernet.in/shp/061305/ Webmaster: http://www.drkapoorsclinic.com Blog: http://divyekapoor.blogspot.com |
|
From: Dean M. B. <mik...@gm...> - 2008-09-08 07:01:08
|
On Mon, Sep 8, 2008 at 2:47 PM, Kim Gräsman <kim...@gm...> wrote: > Hi Dean, > > Looks cool! > > On Mon, Sep 8, 2008 at 07:51, Dean Michael Berris > <mik...@gm...> wrote: >> >> * http::client::follow_redirects / http::client::follow_redirect -- > > I took this to mean there are two options -- what's the difference > between follow_redirects and follow_redirect? How far it follows? > Nope, you can use either option to mean the same thing. >> The following are TODO's related to these two new features: >> - Expiring resolved cached endpoints (configurable?) >> - Limiting the depth of redirect resolution (configurable?) > > This got me thinking about the corner case of circular redirects -- a > depth limit would solve that. Should the limit have a conservative > default? > Right now it doesn't. I'm still thinking about how to go about it. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-08 06:47:39
|
Hi Dean, Looks cool! On Mon, Sep 8, 2008 at 07:51, Dean Michael Berris <mik...@gm...> wrote: > > * http::client::follow_redirects / http::client::follow_redirect -- I took this to mean there are two options -- what's the difference between follow_redirects and follow_redirect? How far it follows? > The following are TODO's related to these two new features: > - Expiring resolved cached endpoints (configurable?) > - Limiting the depth of redirect resolution (configurable?) This got me thinking about the corner case of circular redirects -- a depth limit would solve that. Should the limit have a conservative default? Thanks, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-09-08 05:51:35
|
Hi Guys, I'd just like to post on the list two additional constructor options which the http::client now supports (mainly a brain dump for documentation): Enabling http::client features can be done by passing constructor options. These two new constructor options are: * http::client::cache_resolved -- enable caching of resolved endpoints, to prevent the client from resolving IP addresses of previously resolved hostnames * http::client::follow_redirects / http::client::follow_redirect -- follow HTTP redirect(s) (300..307) by looking at the "Location" header provided by the response(s); headers present in the original request are preserved in the subsequent request(s). A new member function 'clear_cached()' has been added to clear the resolved endpoint cache. The following are TODO's related to these two new features: - Expiring resolved cached endpoints (configurable?) - Limiting the depth of redirect resolution (configurable?) - Use Boost.Parameters library to enable named parameters The default behavior of the http::client (when default constructed) is to: * NOT cache resolved endpoints * NOT follow redirects Questions and discussion most welcome (this is in preparation for release 0.3) HTH! -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Dean M. B. <mik...@gm...> - 2008-09-08 05:29:02
|
Hi Diyve, On Sun, Sep 7, 2008 at 2:47 AM, Divye Kapoor <div...@gm...> wrote: > Hi Dean, > > On Thu, Aug 7, 2008 at 4:00 PM, Dean Michael C. Berris > <dmb...@fr...> wrote: >> >> <snip> >> >> Now though the problem >> you reported earlier (causing the HTTP client to be unusable offline) >> now at least throws a boost::system::system_error exception instead of >> consumes 100% CPU load. > > I've found another case where the http::client is causing resource leaks and > mammoth CPU loads. It occurs when you try to access a CGI script that has > failed to execute. > > A way to reproduce this is to simply use the version of requestinfo.py > before revision 77 (use revision 65) and perform a default POST request on > it. The cgi script fails with an error but the http::client fails to respond > and eats up system resources (seen on Vista/MSVC8). > > I think its a sign of a larger problem with the way we are using getline > calls in http::client. But I'm not sure. Can anyone shed some light on this? > Hmmm... I don't do getline() anymore, except from getting the headers, which should throw if the server has already closed the connection (connection reset). Can you write something that will induce this behavior without having to revert the version of requestinfo.py? Thanks for reporting this. Looking forward to the test. ;-) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Dean M. B. <mik...@gm...> - 2008-09-08 05:25:16
|
Hi Divye, On Sun, Sep 7, 2008 at 2:37 AM, Divye Kapoor <div...@gm...> wrote: > Hi Dean, > > On Fri, Aug 22, 2008 at 12:43 PM, Dean Michael Berris > <mik...@gm...> wrote: >> >> Right, but I'm more interested in something that can be made part of >> the unit tests so that I can verify whether the http::client we have >> has really sets the User-Agent header. > > I've committed a change (changeset 85) that allows you to see the HTTP > headers in the response from cgi-bin/requestinfo.py > There are a couple of bugs in the library that put in non-existent headers > in the response. However, it should be sufficient to test for setting of > http headers. > When you say "there are a couple of bugs in the library", which library are you referring to? And what exactly is the bug? > I'm thinking of refactoring the entire file to make parsing of the response > easy. > What would be the ideal response from the CGI script? CSV, XML or something > else? > Currently, the response is rather kludgy to parse. > Tab/space separated values work -- they can easily be parsed through std::ostringstream's -- as well as doing a '\n' delimited lines for pseudo-CSV. > Comments would be helpful. HTH (BTW, I'll take a look at your code to see if anything breaks in cpp-netlib) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Dean M. B. <mik...@gm...> - 2008-09-08 05:18:59
|
Hi Guys, I've just checked in the patch sent to me by Kim Grasman to the http_integration branch (r86). I haven't built/run this in Linux yet, so I'll have more to say later when I get to it. HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Divye K. <div...@gm...> - 2008-09-06 18:47:34
|
Hi Dean, On Thu, Aug 7, 2008 at 4:00 PM, Dean Michael C. Berris < dmb...@fr...> wrote: > <snip> Now though the problem > you reported earlier (causing the HTTP client to be unusable offline) > now at least throws a boost::system::system_error exception instead of > consumes 100% CPU load. > I've found another case where the http::client is causing resource leaks and mammoth CPU loads. It occurs when you try to access a CGI script that has failed to execute. A way to reproduce this is to simply use the version of requestinfo.py before revision 77 (use revision 65) and perform a default POST request on it. The cgi script fails with an error but the http::client fails to respond and eats up system resources (seen on Vista/MSVC8). I think its a sign of a larger problem with the way we are using getline calls in http::client. But I'm not sure. Can anyone shed some light on this? Divye -- An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup. H. L. Mencken (1880 - 1956) My official web site: http://people.iitr.ernet.in/shp/061305/ Webmaster: http://www.drkapoorsclinic.com Blog: http://divyekapoor.blogspot.com |
|
From: Divye K. <div...@gm...> - 2008-09-06 18:37:32
|
Hi Dean, On Fri, Aug 22, 2008 at 12:43 PM, Dean Michael Berris < mik...@gm...> wrote: > Right, but I'm more interested in something that can be made part of > the unit tests so that I can verify whether the http::client we have > has really sets the User-Agent header. > I've committed a change (changeset 85) that allows you to see the HTTP headers in the response from cgi-bin/requestinfo.py There are a couple of bugs in the library that put in non-existent headers in the response. However, it should be sufficient to test for setting of http headers. I'm thinking of refactoring the entire file to make parsing of the response easy. What would be the ideal response from the CGI script? CSV, XML or something else? Currently, the response is rather kludgy to parse. Comments would be helpful. Divye -- An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup. H. L. Mencken (1880 - 1956) My official web site: http://people.iitr.ernet.in/shp/061305/ Webmaster: http://www.drkapoorsclinic.com Blog: http://divyekapoor.blogspot.com |
|
From: K. G. <kim...@gm...> - 2008-09-05 18:16:05
|
Hi there, On Fri, Sep 5, 2008 at 12:38, Divye Kapoor <div...@gm...> wrote: > >> I think it's better you raise it with the Python developers mailing >> list and submit a patch there. > > I agree. I bounced this with the Python devs, and after almost logging a bug, I noticed that it's fixed in their trunk. The Python 2.6 release will have this bug fixed. I'm not so sure about the space-in-paths thing, but first things first :) Case closed, - Kim |
|
From: K. G. <kim...@gm...> - 2008-09-05 11:22:41
|
Hi Dean, On Fri, Sep 5, 2008 at 11:27, Dean Michael Berris <mik...@gm...> wrote: > > I was hasty in praising the patch... But the fact that you're copying > code from Python (which I think is GPLed) and modifying it to be > applied to a Boost Licensed project/file is going to raise some red > flags. > > IANAL, but I think we cannot merge this based on licensing issues. Yep, it didn't occur to me at the time, but when you mentioned the word "license", it seemed like a risky thing. Based on the Python license Divye posted, it looks pretty safe, but what do I know? > I think it's better you raise it with the Python developers mailing > list and submit a patch there. Yes, I think I will bounce it over there, just to see if I can move this forward. > That said, I don't think spending any more time in this unit test just > to make it work in Windows where Python is broken isn't the best thing > to do at the moment. The simplest thing (and most effective thing) to > do is to mark it as an expected failure in Windows. Sure, I agree. I just thought I had it canned :) > As for better use of time, adding more tests would be nice -- for > example, adding a test for making sure POST works through the CGI > script, the permutations of the .post(...) API call. This looks like something I could spend some time on. > If you're up for it, refactoring the URI parser would be a nice thing > to do too -- to move it from network/protocol/http/impl/request.hpp to > a different file in network/utils/. This looks like fun as well, we'll see if I can find some time to look into it. I wouldn't want to claim it, though, so if anybody else is up for it, feel free. > I hope you understand that there are other more important things to > fix than this single failing unit test where the cause of the failure > is a third-party application we so happen to use for testing (which > apparently doesn't have problems in other platforms). Absolutely. Though I must admit that getting all tests to run on Windows is a priority for me, as that's my base platform. Cheers, - Kim |
|
From: Divye K. <div...@gm...> - 2008-09-05 10:38:12
|
Hi Kim, Dean, On Fri, Sep 5, 2008 at 2:57 PM, Dean Michael Berris <mik...@gm...>wrote: > On Fri, Sep 5, 2008 at 4:03 PM, Kim Gräsman <kim...@gm...> wrote: > > Dean, Divye, > > > > On Fri, Sep 5, 2008 at 09:37, Dean Michael Berris > > <mik...@gm...> wrote: > >> > >> Divye, since this is your code, would you mind taking a look and > >> applying the patch and maybe committing if it's alright with you? I'm > >> guessing the change has to be under the Boost Software License as > >> well. ;-) > > > > I'm not sure if there could be any license issues, as I copied and > > modified two methods from the Python base lib. > > > > I was hasty in praising the patch... But the fact that you're copying > code from Python (which I think is GPLed) and modifying it to be > applied to a Boost Licensed project/file is going to raise some red > flags. > Python has its own license ( http://www.python.org/download/releases/2.5.1/license/) that is not incompatible with the GPL but doesn't have its copyleft clause. The relevant clauses are reproduced for your opinions: 2. Subject to the terms and conditions of this License Agreement, PSF hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python alone or in any derivative version, provided, however, that PSF's License Agreement and PSF's notice of copyright, i.e., "Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006 Python Software Foundation; All Rights Reserved" are retained in Python alone or in any derivative version prepared by Licensee. 3. In the event Licensee prepares a derivative work that is based on or incorporates Python or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to Python. I don't know how this license will interoperate with the BSL, but it doesn't seem to be incompatible like the GPL. Any opinions? > > I think it's better you raise it with the Python developers mailing > list and submit a patch there. > I agree. Divye -- An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup. H. L. Mencken (1880 - 1956) My official web site: http://people.iitr.ernet.in/shp/061305/ Webmaster: http://www.drkapoorsclinic.com Blog: http://divyekapoor.blogspot.com |
|
From: Dean M. B. <mik...@gm...> - 2008-09-05 09:27:46
|
On Fri, Sep 5, 2008 at 4:03 PM, Kim Gräsman <kim...@gm...> wrote: > Dean, Divye, > > On Fri, Sep 5, 2008 at 09:37, Dean Michael Berris > <mik...@gm...> wrote: >> >> Divye, since this is your code, would you mind taking a look and >> applying the patch and maybe committing if it's alright with you? I'm >> guessing the change has to be under the Boost Software License as >> well. ;-) > > I'm not sure if there could be any license issues, as I copied and > modified two methods from the Python base lib. > I was hasty in praising the patch... But the fact that you're copying code from Python (which I think is GPLed) and modifying it to be applied to a Boost Licensed project/file is going to raise some red flags. IANAL, but I think we cannot merge this based on licensing issues. > I'll see if I can vent this on some Python list as well, unless > there's someone here involved in Python (this is the first time I see > Python code :-/) that would care to carry it forward. It'd be nice if > this could go in the main distro, unless there's something wrong with > the approach. > I think it's better you raise it with the Python developers mailing list and submit a patch there. That said, I don't think spending any more time in this unit test just to make it work in Windows where Python is broken isn't the best thing to do at the moment. The simplest thing (and most effective thing) to do is to mark it as an expected failure in Windows. As for better use of time, adding more tests would be nice -- for example, adding a test for making sure POST works through the CGI script, the permutations of the .post(...) API call. If you're up for it, refactoring the URI parser would be a nice thing to do too -- to move it from network/protocol/http/impl/request.hpp to a different file in network/utils/. I hope you understand that there are other more important things to fix than this single failing unit test where the cause of the failure is a third-party application we so happen to use for testing (which apparently doesn't have problems in other platforms). Thanks, and I hope this helps. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-05 08:03:59
|
Dean, Divye, On Fri, Sep 5, 2008 at 09:37, Dean Michael Berris <mik...@gm...> wrote: > > Divye, since this is your code, would you mind taking a look and > applying the patch and maybe committing if it's alright with you? I'm > guessing the change has to be under the Boost Software License as > well. ;-) I'm not sure if there could be any license issues, as I copied and modified two methods from the Python base lib. I'll see if I can vent this on some Python list as well, unless there's someone here involved in Python (this is the first time I see Python code :-/) that would care to carry it forward. It'd be nice if this could go in the main distro, unless there's something wrong with the approach. Thanks, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-09-05 07:37:25
|
Hi Kim, On Fri, Sep 5, 2008 at 3:13 PM, Kim Gräsman <kim...@gm...> wrote: > Hi all, > > Attached is a patch based on http_integration rev. 84, that fixes > cgi_server.py not to strip out CRs. > > I've overridden the code that opens the file on the server-side not to > open as text for content-types beginning with "text/" -- it just > always opens as binary, which makes more sense to me, since all it > does with the content is to stream it out to the client. > > This should neatly solve the whole CRLF debacle :) > Nice. :) Divye, since this is your code, would you mind taking a look and applying the patch and maybe committing if it's alright with you? I'm guessing the change has to be under the Boost Software License as well. ;-) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-05 07:13:22
|
Hi all, Attached is a patch based on http_integration rev. 84, that fixes cgi_server.py not to strip out CRs. I've overridden the code that opens the file on the server-side not to open as text for content-types beginning with "text/" -- it just always opens as binary, which makes more sense to me, since all it does with the content is to stream it out to the client. This should neatly solve the whole CRLF debacle :) Cheers, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-09-05 00:46:30
|
Hi Kim, On Fri, Sep 5, 2008 at 4:33 AM, Kim Gräsman <kim...@gm...> wrote: > > Is it better to submit patches for the http_integration branch, for > example, as it seems there's where most development happens? > Right, if it's anything related to the HTTP implementation, it's going to be the http_integration branch. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-04 20:33:10
|
Hello, If I want to keep up on the latest developments, which branch should I keep checked out? I've been looking at the trunk lately, but I think there's lots of exciting things going on elsewhere :) Is it better to submit patches for the http_integration branch, for example, as it seems there's where most development happens? Thanks, - Kim |
7 messages has been excluded from this view by a project administrator.
