Menu
▾
▴
cpp-netlib-devel
|
From: K. G. <kim...@gm...> - 2008-09-02 12:27:19
|
Hi guys, The localhost_tests suite is failing for me, out of the box, with the following: -- Running 12 test cases... libs/network/test/localhost_tests.cpp(190): error in "text_file_query": check body(response_).length() == size failed [113 != 117] libs/network/test/localhost_tests.cpp(260): fatal error in "cgi_query": exception thrown by r = c.get(req) libs/network/test/localhost_tests.cpp(271): fatal error in "cgi_multi_line_headers": exception thrown by r = c.get(req) *** 3 failures detected in test suite "http 1.0 localhost tests" -- This is on Windows XP SP2, VC 9.0 (no service pack), Boost 1.37 (straight from the SVN trunk) and Python 2.5.2. I haven't investigated the latter two closely (it appears they aren't getting any body whatsoever), but the first one is strange. The file size of test.xml, according to Windows Explorer, is 117 bytes, but the Python script is only serving 113 bytes (I checked this with Firefox as a client as well). So... I'm not sure where it's going wrong. Any ideas on where to start looking? It looks like it might be some kind of encoding mismatch, perhaps? Also, there seems to be a race condition where the tests occasionally launch before Python has had a chance to start, but I think that may be solvable by extracting the server start out into a global fixture (something I'm working on here -- patch coming). Thanks for any input on the first issue! - Kim |
|
From: Dean M. C. B. <dmb...@fr...> - 2008-09-02 12:35:01
|
Hi Kim, > -----Original Message----- > From: cpp...@li... > [mailto:cpp...@li...] On > Behalf Of Kim Gräsman > Sent: Tuesday, September 02, 2008 8:27 PM > To: C++ Networking Library Developers Mailing List > Subject: [cpp-netlib-devel] localhost_tests failures > > Hi guys, > > The localhost_tests suite is failing for me, out of the box, > with the following: > > -- > Running 12 test cases... > libs/network/test/localhost_tests.cpp(190): error in > "text_file_query": check body(response_).length() == size failed [113 > != 117] > libs/network/test/localhost_tests.cpp(260): fatal error in > "cgi_query": exception thrown by r = c.get(req) > libs/network/test/localhost_tests.cpp(271): fatal error in > "cgi_multi_line_headers": exception thrown by r = c.get(req) > > *** 3 failures detected in test suite "http 1.0 localhost tests" > -- > > This is on Windows XP SP2, VC 9.0 (no service pack), Boost 1.37 > (straight from the SVN trunk) and Python 2.5.2. > > I haven't investigated the latter two closely (it appears they aren't > getting any body whatsoever), but the first one is strange. The file > size of test.xml, according to Windows Explorer, is 117 bytes, but the > Python script is only serving 113 bytes (I checked this with Firefox > as a client as well). > The issue has something to do with Python bugs that Divye has posted to the list earlier. There's currently no workaround for this, since we haven't been implementing an HTTP Server in the library yet. At any rate, this doesn't manifest itself in Linux. > So... I'm not sure where it's going wrong. Any ideas on where to start > looking? It looks like it might be some kind of encoding mismatch, > perhaps? > Currently there's no encoding handling that goes on in cpp-netlib -- we deal with raw bytes that come from the wire, which we treat as character buffers. Like I mentioned already, it's a Python in Windows bug. ;) > Also, there seems to be a race condition where the tests occasionally > launch before Python has had a chance to start, but I think that may > be solvable by extracting the server start out into a global fixture > (something I'm working on here -- patch coming). > Looking forward to the patch. :) HTH -- Dean Michael Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-02 13:18:06
Attachments:
python-line-endings.patch
|
Hi Dean, > The issue has something to do with Python bugs that Divye has posted to the list earlier. Ah, found it now, you ironed this out just before I joined! > There's currently no workaround for this, since we haven't been implementing an HTTP Server in the library yet. At any rate, this doesn't manifest itself in Linux. I figured out one workaround -- save test.xml with Unix line-endings (i.e. LF only). That way Python gets what it expects, and the C++ code reading the file sees the same thing. For the ones with no body, that's because my *Python* installation is in Program Files, so both Python and the cpp-netlib source need to live in a space-free path. Ugh. I'll reinstall Python. Attached is a patch for the modified test.xml and adjusted localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble handling changes only in line endings, so whoever commits this may need to alter test.xml manually to make it use Unix line-endings. This seems like a nice thing to get in place, I have some more coming. - Kim |
|
From: Glyn M. <gly...@gm...> - 2008-09-02 13:28:45
|
Hi, 2008/9/2 Kim Gräsman <kim...@gm...> > > Attached is a patch for the modified test.xml and adjusted > localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble > handling changes only in line endings, so whoever commits this may > need to alter test.xml manually to make it use Unix line-endings. > I don't think that is necessary, I think its possible to set it using svn:eol-style: http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5 G |
|
From: K. G. <kim...@gm...> - 2008-09-02 13:34:46
|
Hi Glyn, On Tue, Sep 2, 2008 at 15:28, Glyn Matthews <gly...@gm...> wrote: > Hi, > > 2008/9/2 Kim Gräsman <kim...@gm...> >> >> Attached is a patch for the modified test.xml and adjusted >> localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble >> handling changes only in line endings, so whoever commits this may >> need to alter test.xml manually to make it use Unix line-endings. > > I don't think that is necessary, I think its possible to set it using > svn:eol-style: > > http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5 That looks like it should keep it correct moving forward! I know my patch files contains Unix line-endings for the replaced lines, but it didn't seem to come through when I applied it -- that's probably because the default EOL style is native and so TSVN translates it (helpfully) into CRLF. So, if you would want to commit this, please do as Glyn suggests, and apply the svn:eol-style property to test.xml, set to LF. Thanks, - Kim |
|
From: K. G. <kim...@gm...> - 2008-09-02 13:41:12
|
On Tue, Sep 2, 2008 at 15:34, Kim Gräsman <kim...@gm...> wrote: > > So, if you would want to commit this, please do as Glyn suggests, and > apply the svn:eol-style property to test.xml, set to LF. I tried, but I can't get it to follow through in a .patch -- the propset gets recorded, but it doesn't update the line endings in place... Anyway, please change line endings and the EOL style property, and the committed version should build and run tests successfully out of the box. Thanks, - Kim |
|
From: Divye K. <div...@gm...> - 2008-09-02 13:43:26
|
On Tue, Sep 2, 2008 at 6:48 PM, Kim Gräsman <kim...@gm...> wrote: > I figured out one workaround -- save test.xml with Unix line-endings > (i.e. LF only). That way Python gets what it expects, and the C++ code > reading the file sees the same thing. > > <snip> > Attached is a patch for the modified test.xml and adjusted > localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble > handling changes only in line endings, so whoever commits this may > need to alter test.xml manually to make it use Unix line-endings. > I would not advise such a commit as it atleast prevents *us* from munging line endings while handling text bodies. Even though it might seem nice to resolve this issue via a file that doesn't have CRLF line breaks, I would suggest that it be resolved by changing the test case to reflect the reduced file size in the case of Windows/Python combination. 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-02 13:49:35
|
Hi Divye, On Tue, Sep 2, 2008 at 15:43, Divye Kapoor <div...@gm...> wrote: >> >> Attached is a patch for the modified test.xml and adjusted >> localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble >> handling changes only in line endings, so whoever commits this may >> need to alter test.xml manually to make it use Unix line-endings. > > I would not advise such a commit as it atleast prevents *us* from munging > line endings while handling text bodies. I'm not sure I understand... Are you saying it could mask bugs in cpp-netlib? Could you elaborate? > Even though it might seem nice to > resolve this issue via a file that doesn't have CRLF line breaks, I would > suggest that it be resolved by changing the test case to reflect the reduced > file size in the case of Windows/Python combination. True, that seems like a safer workaround. I'll get to it. - Kim |
|
From: Divye K. <div...@gm...> - 2008-09-02 15:59:21
|
On Tue, Sep 2, 2008 at 7:19 PM, Kim Gräsman <kim...@gm...> wrote: > Hi Divye, > > On Tue, Sep 2, 2008 at 15:43, Divye Kapoor <div...@gm...> wrote: > >> > >> Attached is a patch for the modified test.xml and adjusted > >> localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble > >> handling changes only in line endings, so whoever commits this may > >> need to alter test.xml manually to make it use Unix line-endings. > > > > I would not advise such a commit as it atleast prevents *us* from munging > > line endings while handling text bodies. > > I'm not sure I understand... Are you saying it could mask bugs in > cpp-netlib? Could you elaborate? > As of now, we are not touching the response body given by the server. Right now, we know that the python server is returning fewer characters of the body than expected and we are retaining it bit for bit, allowing the test to fail on Windows. However, if we do need to process the body at some other stage, say to support multipart responses, it would be helpful to retain the test with the CRLF line endings to ensure that non-native line endings are being processed properly by the library while handling the body. 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-02 20:29:57
|
Hi Divye, On Tue, Sep 2, 2008 at 17:41, Divye Kapoor <div...@gm...> wrote: > >> > I would not advise such a commit as it atleast prevents *us* from >> > munging >> > line endings while handling text bodies. >> >> I'm not sure I understand... Are you saying it could mask bugs in >> cpp-netlib? Could you elaborate? > > As of now, we are not touching the response body given by the server. Right > now, we know that the python server is returning fewer characters of the > body than expected and we are retaining it bit for bit, allowing the test to > fail on Windows. Right. But I'm suggesting we should start from data that the Python server does not destroy, allowing the test to *succeed* on all platforms. > However, if we do need to process the body at some other > stage, say to support multipart responses, it would be helpful to retain > the test with the CRLF line endings to ensure that non-native line endings > are being processed properly by the library while handling the body. As it currently stands, the library will only ever receive LF from the Python server, no matter what the source data looks like, as some Python library strips CR from all line ends. I'm not sure what you mean by "non-native line endings", but the Python server will always return LF-only (until that bug is fixed in Python, which looks like it could take a while) so the CRLF file will only serve to test Python, not our client library... Or am I still missing something? Thanks, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-09-03 05:47:51
|
Hi Kim, On Wed, Sep 3, 2008 at 4:29 AM, Kim Gräsman <kim...@gm...> wrote: > > On Tue, Sep 2, 2008 at 17:41, Divye Kapoor <div...@gm...> wrote: >> >> As of now, we are not touching the response body given by the server. Right >> now, we know that the python server is returning fewer characters of the >> body than expected and we are retaining it bit for bit, allowing the test to >> fail on Windows. > > Right. But I'm suggesting we should start from data that the Python > server does not destroy, allowing the test to *succeed* on all > platforms. > Actually, I wouldn't worry about this -- we're hitting a bug in a third-party application that we so happen use in our development/testing. It's by no means a big deal that we're hitting that bug. Although I understand the importance of keeping the build/test clean, we can mark this as an expected failure in Windows+Python(2.5/2.6) -- which by no means reflects as a bug in cpp-netlib. >> However, if we do need to process the body at some other >> stage, say to support multipart responses, it would be helpful to retain >> the test with the CRLF line endings to ensure that non-native line endings >> are being processed properly by the library while handling the body. > > As it currently stands, the library will only ever receive LF from the > Python server, no matter what the source data looks like, as some > Python library strips CR from all line ends. > Not in Linux. > I'm not sure what you mean by "non-native line endings", but the > Python server will always return LF-only (until that bug is fixed in > Python, which looks like it could take a while) so the CRLF file will > only serve to test Python, not our client library... > This is in Windows only, which is not a big deal. > Or am I still missing something? > I think it's all about whether we want to live with the test failure in Windows based on a perfectly valid test that exposes a bug in Python in Windows. In this case I think it's alright for us to live with it -- we can mark it as an expected failure if we're in Windows. Perhaps a patch to the test to reflect this would be very welcome. :) HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-03 06:29:33
|
Hi Dean, On Wed, Sep 3, 2008 at 07:47, Dean Michael Berris <mik...@gm...> wrote: > > I think it's all about whether we want to live with the test failure > in Windows based on a perfectly valid test that exposes a bug in > Python in Windows. In this case I think it's alright for us to live > with it -- we can mark it as an expected failure if we're in Windows. I don't see how that's an improvement over saving test.xml with LF-only line endings, and get consistent test results...? I understood Divye's point to be that if we did that, we would mask something else. Wait... OK, I think I see what's happening: 1) test.xml always contains CRLF, even on Linux 2) On Linux, the Python server serves test.xml with CRLF endings intact 3) If we change test.xml to LF-only, we have worse test coverage for line ending independence Is that it? > Perhaps a patch to the test to reflect this would be very welcome. :) It's included in the patch I sent last night -- in Win32 configurations the test code strips all CRs from the source text document. But maybe a dedicated test would be better to demonstrate this. Thanks, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-09-03 06:44:08
|
Hi Kim, On Wed, Sep 3, 2008 at 2:29 PM, Kim Gräsman <kim...@gm...> wrote: > Hi Dean, > > On Wed, Sep 3, 2008 at 07:47, Dean Michael Berris > <mik...@gm...> wrote: >> >> I think it's all about whether we want to live with the test failure >> in Windows based on a perfectly valid test that exposes a bug in >> Python in Windows. In this case I think it's alright for us to live >> with it -- we can mark it as an expected failure if we're in Windows. > > I don't see how that's an improvement over saving test.xml with > LF-only line endings, and get consistent test results...? I understood > Divye's point to be that if we did that, we would mask something else. > It's not about changing the test data to make sure the tests run, it's more about making sure we get the correct data that we expect from the HTTP Server -- and if I requested for a file that has CRLF line endings in from the server, that I would get the exact same file if I read it from disk in binary mode. > Wait... OK, I think I see what's happening: > > 1) test.xml always contains CRLF, even on Linux > 2) On Linux, the Python server serves test.xml with CRLF endings intact > 3) If we change test.xml to LF-only, we have worse test coverage for > line ending independence > > Is that it? > Yes, we want to make sure CRLF is preserved -- and that the file is intact when sent over the HTTP Server, and received by the client. >> Perhaps a patch to the test to reflect this would be very welcome. :) > > It's included in the patch I sent last night -- in Win32 > configurations the test code strips all CRs from the source text > document. But maybe a dedicated test would be better to demonstrate > this. > I would like to see though a windows-specific flag which sets the expected failures to 1 in the localhost_test case that checks for file lengths. I haven't taken a look at your patch yet, so I'll see what happens when I get to it later. HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Divye K. <div...@gm...> - 2008-09-03 06:50:53
|
On Wed, Sep 3, 2008 at 11:59 AM, Kim Gräsman <kim...@gm...> wrote: > Wait... OK, I think I see what's happening: > > 1) test.xml always contains CRLF, even on Linux > 2) On Linux, the Python server serves test.xml with CRLF endings intact > 3) If we change test.xml to LF-only, we have worse test coverage for > line ending independence > > Is that it? > That's just it. :-) 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-03 07:17:35
|
Hi Divye, On Wed, Sep 3, 2008 at 08:50, Divye Kapoor <div...@gm...> wrote: > > On Wed, Sep 3, 2008 at 11:59 AM, Kim Gräsman <kim...@gm...> wrote: >> >> Wait... OK, I think I see what's happening: >> >> 1) test.xml always contains CRLF, even on Linux >> 2) On Linux, the Python server serves test.xml with CRLF endings intact >> 3) If we change test.xml to LF-only, we have worse test coverage for >> line ending independence >> >> Is that it? > > That's just it. :-) Cool, thanks :) I'm still not happy with having the test fail on Windows due to a known bug in a third party, but now I understand why converting line endings on test.xml can be problematic. I think my main concern is that marking the test as an expected failure makes it useless--if failure is expected, the only way it can demonstrate a change in behavior is if Python suddenly starts working. That said, if we're worried about line endings causing trouble, shouldn't we have targetted tests for that? Cheers, - Kim |
|
From: K. G. <kim...@gm...> - 2008-09-03 07:00:26
|
Hi Dean, On Wed, Sep 3, 2008 at 08:44, Dean Michael Berris <mik...@gm...> wrote: > >> I don't see how that's an improvement over saving test.xml with >> LF-only line endings, and get consistent test results...? I understood >> Divye's point to be that if we did that, we would mask something else. >> > > It's not about changing the test data to make sure the tests run, it's > more about making sure we get the correct data that we expect from the > HTTP Server -- and if I requested for a file that has CRLF line > endings in from the server, that I would get the exact same file if I > read it from disk in binary mode. The thing is, the server you're using cannot serve a file containing CRLF "for technical reasons" -- wouldn't it seem better to base the test off a file with LF only? That way you preserve the premise of the test, but change the details to compensate for the "technical reasons", so that the test is still valid. - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-09-03 07:28:54
|
On Wed, Sep 3, 2008 at 3:00 PM, Kim Gräsman <kim...@gm...> wrote: > Hi Dean, > > On Wed, Sep 3, 2008 at 08:44, Dean Michael Berris > <mik...@gm...> wrote: >> >>> I don't see how that's an improvement over saving test.xml with >>> LF-only line endings, and get consistent test results...? I understood >>> Divye's point to be that if we did that, we would mask something else. >>> >> >> It's not about changing the test data to make sure the tests run, it's >> more about making sure we get the correct data that we expect from the >> HTTP Server -- and if I requested for a file that has CRLF line >> endings in from the server, that I would get the exact same file if I >> read it from disk in binary mode. > > The thing is, the server you're using cannot serve a file containing > CRLF "for technical reasons" -- wouldn't it seem better to base the > test off a file with LF only? > > That way you preserve the premise of the test, but change the details > to compensate for the "technical reasons", so that the test is still > valid. > We're not testing the serving of the file -- because that's Python's domain, and we're not testing the Python server -- but rather we're testing the reception of the file to make sure that *if* and *when* the file contains CRLF line endings, that we catch it as is. The premise of the test is: - when we request a file that has CRLF line endings, we get it with CRLF line endings - cpp-netlib will not fail because having CRLF line endings in the body should be acceptable - CRLF line endings are preserved when the body of an http::response is retrieved. Of course, it assumes that the HTTP server will serve the file correctly. In this case the problem is no longer the client, but the server. In which case, since this failure only happens in Windows with Python, and that it's a known bug in the server, then it's best that we mark it as an expected failure due to a bug in the third party. If there was anything that was going to be fixed, it is the Python server, not the unit test or the test data. ;-) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-03 08:08:28
|
Hi Dean, On Wed, Sep 3, 2008 at 09:28, Dean Michael Berris <mik...@gm...> wrote: > > We're not testing the serving of the file -- because that's Python's > domain, and we're not testing the Python server -- but rather we're > testing the reception of the file to make sure that *if* and *when* > the file contains CRLF line endings, that we catch it as is. Right. > The premise of the test is: > - when we request a file that has CRLF line endings, we get it with > CRLF line endings > - cpp-netlib will not fail because having CRLF line endings in the > body should be acceptable > - CRLF line endings are preserved when the body of an http::response > is retrieved. Ah, are the CRLF line endings the primary feature of this test? It hasn't occurred to me, but text_file_query probably implies something about the line endings... Maybe both should be covered, e.g. text_query_crlf_preserved text_query_lf_preserved The first would have to be ignored on Windows, as there's no way of making that pass with the current Python implementation. Are we getting closer? :) Thanks, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-09-03 08:19:28
|
On Wed, Sep 3, 2008 at 4:08 PM, Kim Gräsman <kim...@gm...> wrote: > >> The premise of the test is: >> - when we request a file that has CRLF line endings, we get it with >> CRLF line endings >> - cpp-netlib will not fail because having CRLF line endings in the >> body should be acceptable >> - CRLF line endings are preserved when the body of an http::response >> is retrieved. > > Ah, are the CRLF line endings the primary feature of this test? > Okay, a bit of history required I think... In the first incarnation (very early implementation) of the http::client, it performed a getline(stream, string) which stripped the line endings from responses. So Divye implemented a test which exposes this bug in the form of files with CRLF line endings. > It hasn't occurred to me, but text_file_query probably implies > something about the line endings... > Right, I think the name would was a little vague too now that I think about it. ;-) > Maybe both should be covered, e.g. > > text_query_crlf_preserved > text_query_lf_preserved > > The first would have to be ignored on Windows, as there's no way of > making that pass with the current Python implementation. > Maybe... But really, I think we shouldn't make too much of a case regarding getting around Python especially since they won't be fixing that bug and since we're only interested in making sure we *do* get the CRLF's when they go through the wire without causing the client to break. > Are we getting closer? :) I personally think just marking it an expected failure on Windows with explicit documentation stating the rationale (citing the Python bug) would be sufficient. Although a test case where we have just LF's would be alright as well. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-03 09:21:23
|
Hi Dean, On Wed, Sep 3, 2008 at 10:19, Dean Michael Berris <mik...@gm...> wrote: > >> Are we getting closer? :) > > I personally think just marking it an expected failure on Windows with > explicit documentation stating the rationale (citing the Python bug) > would be sufficient. That's what I meant, sorry if I wasn't clear. Now I understand what the test is there for, it didn't occur to me earlier that there should be no difference between text/binary, except /possibly/ for handling of line endings -- if the client treats them both as binary, then that's good. Time to make the server do the same ;-) Thanks, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-09-03 09:36:04
|
On Wed, Sep 3, 2008 at 5:21 PM, Kim Gräsman <kim...@gm...> wrote: > > On Wed, Sep 3, 2008 at 10:19, Dean Michael Berris > <mik...@gm...> wrote: >> >>> Are we getting closer? :) >> >> I personally think just marking it an expected failure on Windows with >> explicit documentation stating the rationale (citing the Python bug) >> would be sufficient. > > That's what I meant, sorry if I wasn't clear. > It's alright. :) > Now I understand what the test is there for, it didn't occur to me > earlier that there should be no difference between text/binary, except > /possibly/ for handling of line endings -- if the client treats them > both as binary, then that's good. Time to make the server do the same > ;-) > Right. :-) It would be good to have an HTTP Server part of the library, but it's something that I have yet to get to. Right now I'm still having fun with the client and implementing a client, and it's a good change of pace for me since I've been too involved in developing an HTTP Server from scratch as well for the longest time. ;-) > Thanks, > - Kim > Thank you too. :-) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-09-05 07:13:22
Attachments:
cgi_server_crlf.patch
|
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 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 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 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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X