This list is closed, nobody may subscribe to it.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(116) |
Nov
(24) |
Dec
(127) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(53) |
Feb
(28) |
Mar
(39) |
Apr
(37) |
May
(19) |
Jun
(44) |
Jul
(22) |
Aug
(19) |
Sep
(34) |
Oct
(135) |
Nov
(41) |
Dec
(81) |
2003 |
Jan
(278) |
Feb
(94) |
Mar
(69) |
Apr
(51) |
May
(10) |
Jun
(16) |
Jul
(17) |
Aug
(25) |
Sep
(3) |
Oct
(21) |
Nov
(29) |
Dec
(4) |
2004 |
Jan
(13) |
Feb
(18) |
Mar
(24) |
Apr
(21) |
May
(1) |
Jun
(6) |
Jul
(5) |
Aug
(13) |
Sep
(30) |
Oct
(19) |
Nov
(13) |
Dec
(67) |
2005 |
Jan
(21) |
Feb
(57) |
Mar
(37) |
Apr
(13) |
May
(3) |
Jun
|
Jul
(21) |
Aug
(7) |
Sep
(50) |
Oct
(45) |
Nov
(42) |
Dec
(1) |
2006 |
Jan
(12) |
Feb
(2) |
Mar
(5) |
Apr
(23) |
May
(2) |
Jun
|
Jul
(36) |
Aug
(14) |
Sep
(11) |
Oct
(8) |
Nov
(9) |
Dec
(2) |
2007 |
Jan
(16) |
Feb
(4) |
Mar
(22) |
Apr
(14) |
May
(6) |
Jun
(12) |
Jul
(2) |
Aug
|
Sep
(4) |
Oct
(7) |
Nov
(13) |
Dec
(3) |
2008 |
Jan
|
Feb
(10) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(13) |
Aug
|
Sep
(4) |
Oct
(9) |
Nov
(12) |
Dec
(16) |
2009 |
Jan
(9) |
Feb
(1) |
Mar
(14) |
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(6) |
Jul
|
Aug
(3) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(6) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(4) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2017 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(7) |
Mar
(1) |
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2020 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christoph Z. <ci...@on...> - 2022-07-16 19:38:14
|
Dear Webware for Python developer, since the Webware for Python project is now hosted on GitHub, and we want to streamline our communication channels, the "webware-devel" mailing list will be closed. If you want to contribute a bugfix or a new feature, please open a GitHub issue for that. You can find our GitHub pages here: - https://github.com/WebwareForPython/w4py (Webware for Python 2) - https://github.com/WebwareForPython/w4py3 (Webware for Python 3) The mailing list archive will still be accessible here: https://sourceforge.net/p/webware/mailman/webware-devel/ Unfortunately, SourceForge does not allow us to automatically unsubscribe you, but you can do it yourself here: https://sourceforge.net/projects/webware/lists/webware-devel/unsubscribe All the best and see you on GitHub, Christoph |
From: Christoph Z. <ci...@on...> - 2022-07-16 17:25:49
|
Webware for Python 3.0.6 has been released today. GitHub: https://github.com/WebwareForPython/w4py3 PyPI: https://pypi.org/project/Webware-for-Python/ Documentation: https://webwareforpython.github.io/w4py3/ List of changes in version 3: https://webwareforpython.github.io/w4py3/changes.html Changes in this patch release: https://github.com/WebwareForPython/w4py3/releases/tag/3.0.6 -- Christoph |
From: Christoph Z. <ci...@on...> - 2022-03-20 21:48:51
|
Webware for Python 3.0.5 has been released today. GitHub: https://github.com/WebwareForPython/w4py3 PyPI: https://pypi.org/project/Webware-for-Python/ Documentation: https://webwareforpython.github.io/w4py3/ List of changes in version 3: https://webwareforpython.github.io/w4py3/changes.html Changes in this patch release: https://github.com/WebwareForPython/w4py3/releases/tag/3.0.5 There is also a new version 3.0.2 of DBUtils: https://webwareforpython.github.io/DBUtils/ For those who are still using Webware 1.2.x on a server with vendor-supplied security patches for Python 2, there is also a new maintenance release Webware 1.2.4 that fixes an issue created by a recent security patch. -- Christoph |
From: Christoph Z. <ci...@on...> - 2021-11-26 23:17:48
|
Webware for Python 3.0.4 has been released today. GitHub: https://github.com/WebwareForPython/w4py3 PyPI: https://pypi.org/project/Webware-for-Python/ Documentation: https://webwareforpython.github.io/w4py3/ List of changes in version 3: https://webwareforpython.github.io/w4py3/changes.html Changes in this patch release: https://github.com/WebwareForPython/w4py3/releases/tag/3.0.4 There is also a new version 3.0.0 of DBUtils: https://webwareforpython.github.io/DBUtils/ Stay healthy. Stay happy. -- Christoph |
From: Christoph Z. <ci...@on...> - 2021-04-30 14:54:46
|
Webware for Python 3.0.3 has been released today. GitHub: https://github.com/WebwareForPython/w4py3 PyPI: https://pypi.org/project/Webware-for-Python/ Documentation: https://webwareforpython.github.io/w4py3/ List of changes in version 3: https://webwareforpython.github.io/w4py3/changes.html Changes in this patch release: https://github.com/WebwareForPython/w4py3/releases/tag/3.0.3 Stay healthy. Stay happy. -- Christoph |
From: Christoph Z. <ci...@on...> - 2021-01-21 17:49:05
|
Webware for Python 3.0.2 has been released today. GitHub: https://github.com/WebwareForPython/w4py3 PyPI: https://pypi.org/project/Webware-for-Python/ Documentation: https://webwareforpython.github.io/w4py3/ List of changes in version 3: https://webwareforpython.github.io/w4py3/changes.html Changes in this patch release: https://github.com/WebwareForPython/w4py3/releases/tag/3.0.2 Stay healthy. Stay happy. -- Christoph |
From: Christoph Z. <ci...@on...> - 2020-10-17 20:21:34
|
Correction: The announcement had the wrong subject - this is the final version of Webware for Python 3.0.0, not an alpha version. |
From: Christoph Z. <ci...@on...> - 2020-10-17 20:18:26
|
Hi all, I'm pleased to announce at least one good news in these hard times: After a nearly year-long alpha and beta phase, Webware for Python 3.0.0 has been released today. Here are all the important links: GitHub: https://github.com/WebwareForPython/w4py3 PyPI: https://pypi.org/project/Webware-for-Python/ Documentation: https://webwareforpython.github.io/w4py3/ List of changes: https://webwareforpython.github.io/w4py3/changes.html Mirgration guide: https://webwareforpython.github.io/w4py3/migrate.html The main improvements and changes in Webware for Python 3 are: - Python 3.6 or newer instead of Python 2 - Standard packaging and installation - Entry points for Webware plug-ins - WSGI instead of app server and adapters - Sphinx/ReadTheDocs for documentation - GitHub Actions to run improved test suite The WebKit plug-in has been promoted to the top level and does not exist anymore as a separate plug-in. PSP is still supported. MiddleKit has become an external plug-in now, available at: https://github.com/WebwareForPython/w4py3-middlekit Let me know if there are any pain points, bugs or other problems. You can use GitHub issues, pull requests or the webware mailing list for feedback and sending bug reports or improvements. -- Christoph |
From: Christoph Z. <ci...@on...> - 2020-05-14 16:41:28
|
Hi all, the final ever Python 2 update has been released in April, which also marks the end of the era of Webware for Python 2. But don't despair - Webware for Python 3 has been available as an alpha release since last year, and as a beta release since today. The home page for Webware for Python 3 has been moved here: https://github.com/WebwareForPython/w4py3/ Documentation is available here: https://webwareforpython.github.io/w4py3/ The documentation also lists the changes and explains how to migrate legacy Webware applications. Main improvements and changes: - Use Python 3.6 or newer instead of Python 2 - Use standard packaging and installation - Use entry points for Webware plug-ins - Use WSGI instead of app server and adapters - Use Sphinx/ReadTheDocs for documentation - Use GitHub Actions to run improved test suite The WebKit plug-in has been promoted to the top level and does not exist any more as a separate plug-in. PSP is still built-in. MiddleKit has been removed as a built-in plug-in, but can be installed as an external plug-in available from here: https://github.com/WebwareForPython/w4py3-middlekit Please let me know how you like the beta version, if there are any pain points, bugs or other problems, since I want to release a final version soon. New features and more modernizations will be released in the next minor version. You can use GitHub issues, pull requests or the web...@li... mailing list for feedback and sending bug reports or improvements. Stay healthy and happy! -- Christoph |
From: Christoph Z. <ci...@on...> - 2020-03-04 14:52:51
|
Am 04.03.2020 um 12:26 schrieb F. Behrens: > So as you can see, exactly 7 args are passed to klass. Where could the > 8th be coming from? I guess the 8th one is the "self" arg that is added automatically. Probably you are using Python 2.7 which has added the max_num_fields arg, with an older version of Webware that does not yet support it. I think it is only supported since version 1.2.2. -- Christoph |
From: F. B. <web...@sp...> - 2020-03-04 11:47:51
|
Hi, I got this Traceback in a webware installation today and I sort of fail to see it making sense: ------------------------------------- Traceback (most recent call last): File "/opt/webware/WebKit/ThreadedAppServer.py", line 655, in threadloop handler.handleRequest() File "/opt/webware/WebKit/ThreadedAppServer.py", line 1095, in handleRequest requestDict, streamOut) File "/opt/webware/WebKit/Application.py", line 539, in dispatchRawRequest request = self.createRequestForDict(requestDict) File "/opt/webware/WebKit/Application.py", line 586, in createRequestForDict request = HTTPRequest(requestDict) File "/opt/webware/WebKit/HTTPRequest.py", line 38, in __init__ keep_blank_values=True, strict_parsing=False) File "/opt/webware/WebUtils/FieldStorage.py", line 37, in __init__ environ, keep_blank_values, strict_parsing) File "/usr/lib/python2.7/cgi.py", line 513, in __init__ self.read_multi(environ, keep_blank_values, strict_parsing) File "/usr/lib/python2.7/cgi.py", line 645, in read_multi max_num_fields) TypeError: __init__() takes at most 7 arguments (8 given) ------------------------------------- When looking at cgi.py the failing part looks like: 642 klass = self.FieldStorageClass or self.__class__ 643 part = klass(self.fp, {}, ib, 644 environ, keep_blank_values, strict_parsing, 645 max_num_fields) 646 So as you can see, exactly 7 args are passed to klass. Where could the 8th be coming from? Any ideas appreciated. -- kind regards, Fionn |
From: Mark P. <mar...@mo...> - 2020-01-10 23:24:41
|
Great news! Thanks, Christoph. > On Jan 9, 2020, at 3:25 PM, Christoph Zwerschke <ci...@on...> wrote: > > Happy new year to you all, > > and I am also sharing some happy news: > > > A new version 1.2.3 of Webware for Python 2 has been released. > > Homepage: https://cito.github.io/w4py/ > Project page: https://github.com/Cito/w4py/ > Download from SourceForge: > https://sourceforge.net/projects/webware/files/latest/download > Download from PyPI: > https://pypi.org/project/Webware-for-Python/1.2.3/#files > Release Notes: > http://webware.sourceforge.net/Webware/Docs/RelNotes-1.2.3.html > > > Also, a new apha version 3.0.0a1 of Webware for Python 3 > has been released. > > Homepage: https://cito.github.io/w4py3/ > Project page: https://github.com/Cito/w4py3/ > Download from PyPI: > https://pypi.org/project/Webware-for-Python/3.0.0a1/#files > Latest commits: > https://github.com/Cito/w4py3/commits/master > > > We now also have an alpha version of the MiddleKit Plugin > for Webware for Python 3, which has been made available > as a separate project (not built-in to Webware any more) > https://github.com/PeaceWorksTechnologySolutions/w4py3-middlekit > > > Thanks to Nico Latzer and Jason Hildenbrand for porting MiddleKit > and volunteering to act as its new maintainers. > > Also thanks to everyone who provided feedback and pull requests for the new alpha version of Webware for Python 3. > > Please continue to provide feedback, so that we can move forward and publish a beta version soon. > > > -- Christoph Zwerschke > > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Christoph Z. <ci...@on...> - 2020-01-09 23:38:57
|
Happy new year to you all, and I am also sharing some happy news: A new version 1.2.3 of Webware for Python 2 has been released. Homepage: https://cito.github.io/w4py/ Project page: https://github.com/Cito/w4py/ Download from SourceForge: https://sourceforge.net/projects/webware/files/latest/download Download from PyPI: https://pypi.org/project/Webware-for-Python/1.2.3/#files Release Notes: http://webware.sourceforge.net/Webware/Docs/RelNotes-1.2.3.html Also, a new apha version 3.0.0a1 of Webware for Python 3 has been released. Homepage: https://cito.github.io/w4py3/ Project page: https://github.com/Cito/w4py3/ Download from PyPI: https://pypi.org/project/Webware-for-Python/3.0.0a1/#files Latest commits: https://github.com/Cito/w4py3/commits/master We now also have an alpha version of the MiddleKit Plugin for Webware for Python 3, which has been made available as a separate project (not built-in to Webware any more) https://github.com/PeaceWorksTechnologySolutions/w4py3-middlekit Thanks to Nico Latzer and Jason Hildenbrand for porting MiddleKit and volunteering to act as its new maintainers. Also thanks to everyone who provided feedback and pull requests for the new alpha version of Webware for Python 3. Please continue to provide feedback, so that we can move forward and publish a beta version soon. -- Christoph Zwerschke |
From: Mark P. <mar...@mo...> - 2019-11-17 21:50:42
|
This is very cool, Christoph. I look forward to reviewing the new code base and documents. BTW, the paragraph that begins "The most incisive change in Webware for Python 3…” is repeated in the text. The two are run together so it appears to be one paragraph. Cheers, - Mark Phillips > On Nov 17, 2019, at 12:23 PM, Christoph Zwerschke <ci...@on...> wrote: > > Hi all, > > sorry for the long radio silence. > > As the end of life for Python 2.7 is coming, I have finally taken some time to create a first public alpha release of the long promised new version of Webware for Python that targets Python 3. > > The home page for Webware for Python 3 is here: > https://github.com/Cito/w4py3 > > Documentation is available here: > https://webware-for-python-3.readthedocs.io/ > > The documentation also lists the changes and explains how to migrate existing Webware apps for legacy Python. > > Main improvements and changes: > - Use Python 3.6 or newer instead of Python 2 > - Use standard packaging and installation > - Use entry points for Webware plug-ins > - Use WSGI instead of app server and adapters > - Use Sphinx/ReadTheDocs for documentation > - Use GitHub Actions to run improved test suite > > The WebKit plug-in has been promoted to the top level and does not exist any more as a separate plug-in. PSP is still supported. > > MiddleKit has been removed as a built-in plug-in and must be installed as a yet-to-be-created external plug-in now. If anybody has interest in creating such a Webware for Python 3 compatible MiddleKit and wants to become a maintainer, please let me know. I will gladly help, but cannot act as a maintainer myself any longer. > > Please let me know how you like the new version, if there are any pain points, bugs or other problems. You can use GitHub issues, pull requests or the web...@li... mailing list for feedback and sending bug reports or improvements. > > I will publish more alpha and beta releases in the next weeks depending on how much feedback and bug reports I will get, and hopefully we can then have the final 3.0 release by 2020. > > -- Christoph > > > > > > > > > > > > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Christoph Z. <ci...@on...> - 2019-11-17 20:23:59
|
Hi all, sorry for the long radio silence. As the end of life for Python 2.7 is coming, I have finally taken some time to create a first public alpha release of the long promised new version of Webware for Python that targets Python 3. The home page for Webware for Python 3 is here: https://github.com/Cito/w4py3 Documentation is available here: https://webware-for-python-3.readthedocs.io/ The documentation also lists the changes and explains how to migrate existing Webware apps for legacy Python. Main improvements and changes: - Use Python 3.6 or newer instead of Python 2 - Use standard packaging and installation - Use entry points for Webware plug-ins - Use WSGI instead of app server and adapters - Use Sphinx/ReadTheDocs for documentation - Use GitHub Actions to run improved test suite The WebKit plug-in has been promoted to the top level and does not exist any more as a separate plug-in. PSP is still supported. MiddleKit has been removed as a built-in plug-in and must be installed as a yet-to-be-created external plug-in now. If anybody has interest in creating such a Webware for Python 3 compatible MiddleKit and wants to become a maintainer, please let me know. I will gladly help, but cannot act as a maintainer myself any longer. Please let me know how you like the new version, if there are any pain points, bugs or other problems. You can use GitHub issues, pull requests or the web...@li... mailing list for feedback and sending bug reports or improvements. I will publish more alpha and beta releases in the next weeks depending on how much feedback and bug reports I will get, and hopefully we can then have the final 3.0 release by 2020. -- Christoph |
From: Christoph Z. <ci...@on...> - 2019-08-04 18:31:38
|
Hi all, Webware for Python 1.2.2 is available for download. This is a bugfix and maintenance release. Documentation and download links can be found here: https://cito.github.io/w4py/ Webware for Python 1.x is in maintenance mode now - no new features will be added and only critical bugs or security issues will be fixed. Note that Webware 1.2.x supports Python 2.6 and 2.7 only. I'm planning to create a modernized, but slimmed down version 2.x supporting Python 3 this year - an alpha version will be hopefully available soon. -- Christoph |
From: Kerrison, A. <Ada...@bm...> - 2019-05-23 11:19:58
|
Yes I should have said we are using the built in HTTP server as having apache/mod_webkit in the container just to serve HTTP seemed like overkill. We are definitely interested in the future py3 version. WSGI sounds like a good approach to me. As for sessions, we've got our own but its far from a perfect solution (its good enough right now) -----Original Message----- From: Christoph Zwerschke <ci...@on...> Sent: 23 May 2019 12:12 To: web...@li... Subject: [EXTERNAL] Re: [Webware-devel] socker error handling bug? Am 23.05.2019 um 11:26 schrieb Kerrison, Adam: > Our setup is Browser -> AWS ELB -> nginx load balancer (container in kubernetes) -> webware (container in kubernetes) Ok, so you're using the built-in HTTP server (EnableHTTP=True)? Because the appserver by default cannot be directly used from the browser. Note that the built-in HTTP server (i.e. running the ThreadedAppServer with HTTPAppServerHandler) is actually not a recommended solution for running in production under heavy load since the HTTPAppServerHandler is based on the standard lib's BaseHTTPServer. We are currently thinking about the next Py 3 compatible version of Webware. Are you interested in that as well? My plan is to just provide WSGI so that you can use any WSGI compliant server to serve Webware apps, and remove all the old server related components and adapters from Webware. This will also allow running Webware with multiprocessing. Btw, may I ask whether you use Webware Sessions and which variant? Because if you're using several Webware processes with load balancing, the default Memory/Dynamic session stores don't work. We will also need a new default Session system when supporting multiprocessing. -- Christoph _______________________________________________ Webware-devel mailing list Web...@li... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_webware-2Ddevel&d=DwICAg&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=l4_FjaE8waU_Bx6B51lRoYsFmkmmRUHzG7prcuLRl5c&m=3UlvplCbgxyX7qDDhl3RT_dRSYU7eMtIlHZXBCnbhB4&s=NLOCH5bqXdjPLPAlGcC3nOCUXmtOJUJh_5T7-GSEUBY&e= BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately. |
From: Christoph Z. <ci...@on...> - 2019-05-23 11:11:38
|
Am 23.05.2019 um 11:26 schrieb Kerrison, Adam: > Our setup is Browser -> AWS ELB -> nginx load balancer (container in kubernetes) -> webware (container in kubernetes) Ok, so you're using the built-in HTTP server (EnableHTTP=True)? Because the appserver by default cannot be directly used from the browser. Note that the built-in HTTP server (i.e. running the ThreadedAppServer with HTTPAppServerHandler) is actually not a recommended solution for running in production under heavy load since the HTTPAppServerHandler is based on the standard lib's BaseHTTPServer. We are currently thinking about the next Py 3 compatible version of Webware. Are you interested in that as well? My plan is to just provide WSGI so that you can use any WSGI compliant server to serve Webware apps, and remove all the old server related components and adapters from Webware. This will also allow running Webware with multiprocessing. Btw, may I ask whether you use Webware Sessions and which variant? Because if you're using several Webware processes with load balancing, the default Memory/Dynamic session stores don't work. We will also need a new default Session system when supporting multiprocessing. -- Christoph |
From: Kerrison, A. <Ada...@bm...> - 2019-05-23 09:26:16
|
Our setup is Browser -> AWS ELB -> nginx load balancer (container in kubernetes) -> webware (container in kubernetes) We are using nginx as a Kubernetes Ingress controller and it creates the AWS ELB (several reasons we aren't using the AWS ALB Ingress controller ... yet) Why nginx occasionally cuts the connection I don't know - there is nothing obvious in the error or access logs. I've got the fix in test as its not something that happens all the time but I'm pretty confident catching the conn reset will be fine (as the appserver will stay up) Adam -----Original Message----- From: Christoph Zwerschke <ci...@on...> Sent: 22 May 2019 16:34 To: web...@li... Subject: [EXTERNAL] Re: [Webware-devel] socker error handling bug? Am 22.05.2019 um 16:05 schrieb Kerrison, Adam: > I think the except should be socket.error not select.error ... I don't > think accept() will ever raise a select.error? Or perhaps it should > catch both select.error and socket.error. self._ignoreErrnos does > include ECONNRESET so something is definitely trying to handle it > > If I'm right it surprises me that no one else has reported similar > issues? Or am I totally wrong? Hi Adam, thanks a lot for reporting this. I think you're totally right, this should be socket.error, not select.error. The former is a subclass of IOError (or OSError in Py3), but the latter is a class of its own. And sock.accept() definitely only throws the former - I have looked into the source code in socketmodule.c to confirm that. Maybe nobody noticed because errors are normally caught in the select() call already or upfront by Apache when connected directly via mod_webkit. What is your configuration? apache -> mod_webkit -> nginx as load balancer -> appserver? Did changing this line solve your problem? -- Christoph _______________________________________________ Webware-devel mailing list Web...@li... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_webware-2Ddevel&d=DwIF-g&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=l4_FjaE8waU_Bx6B51lRoYsFmkmmRUHzG7prcuLRl5c&m=naq9uxhuYiVJyLAa59nnocdsAr29Zkey2TSGa09gylY&s=ma4lQ2T-OWjeA6YaekEuaEFtglbuerHME-56PyhKCmM&e= BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately. |
From: Jason H. <ja...@pe...> - 2019-05-22 22:08:42
|
Hi Adam, I believe you are right. I am running a Webware app using an older version of Webware (we have not had funding to upgrade it), and the corresponding code is: # block for timeout seconds waiting for connections try: input, output, exc = select.select( self._sockets.values(), [], [], timeout) except select.error, e: if e.args == 4: # Interrupted system call continue for sock in input: self._requestID += 1 client, addr = sock.accept() serverAddress = sock.getsockname() try: handler = self._handlerCache[serverAddress].pop() except IndexError: handler = self._socketHandlers[serverAddress](self, serverAddress) handler.activate(client, self._requestID) self._requestQueue.put(handler) In this context there is a select() call, and so the except makes sense. I'm guessing that the except in your version of Webware is a leftover from some refactoring which was not updated (it's difficult to test error conditions like this). I'd suggest you prepare and submit a PR to the github repo. Jason ________________________________ From: Kerrison, Adam <Ada...@bm...> Sent: May 22, 2019 9:05 AM To: web...@li... Subject: [Webware-devel] socker error handling bug? Hello We’ve encountered an odd scenario with Webware behind a nginx load balancer. For reasons we don’t yet understand nginx will sometimes make a connection to Webware then immediately close the socket (bizarrely, this seems to be browser related with Firefox clients causing the issue but not Chrome!?). This causes an error 104 “connection reset by peer” in Webware which causes the AppServer to die. Looking at the code in ThreadedAppServer.py I think the exception handling around the accept() call is wrong (line 389): try: client, addr = sock.accept() except select.error as e: if e[0] not in self._ignoreErrnos: raise if debug: print "Socket accept error:", e continue I think the except should be socket.error not select.error … I don’t think accept() will ever raise a select.error? Or perhaps it should catch both select.error and socket.error. self._ignoreErrnos does include ECONNRESET so something is definitely trying to handle it If I’m right it surprises me that no one else has reported similar issues? Or am I totally wrong? Adam BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately. |
From: Christoph Z. <ci...@on...> - 2019-05-22 15:59:08
|
Am 22.05.2019 um 16:05 schrieb Kerrison, Adam: > I think the except should be socket.error not select.error … I don’t > think accept() will ever raise a select.error? Or perhaps it should > catch both select.error and socket.error. self._ignoreErrnos does > include ECONNRESET so something is definitely trying to handle it > > If I’m right it surprises me that no one else has reported similar > issues? Or am I totally wrong? Hi Adam, thanks a lot for reporting this. I think you're totally right, this should be socket.error, not select.error. The former is a subclass of IOError (or OSError in Py3), but the latter is a class of its own. And sock.accept() definitely only throws the former - I have looked into the source code in socketmodule.c to confirm that. Maybe nobody noticed because errors are normally caught in the select() call already or upfront by Apache when connected directly via mod_webkit. What is your configuration? apache -> mod_webkit -> nginx as load balancer -> appserver? Did changing this line solve your problem? -- Christoph |
From: Kerrison, A. <Ada...@bm...> - 2019-05-22 14:39:10
|
Hello We've encountered an odd scenario with Webware behind a nginx load balancer. For reasons we don't yet understand nginx will sometimes make a connection to Webware then immediately close the socket (bizarrely, this seems to be browser related with Firefox clients causing the issue but not Chrome!?). This causes an error 104 "connection reset by peer" in Webware which causes the AppServer to die. Looking at the code in ThreadedAppServer.py I think the exception handling around the accept() call is wrong (line 389): try: client, addr = sock.accept() except select.error as e: if e[0] not in self._ignoreErrnos: raise if debug: print "Socket accept error:", e continue I think the except should be socket.error not select.error ... I don't think accept() will ever raise a select.error? Or perhaps it should catch both select.error and socket.error. self._ignoreErrnos does include ECONNRESET so something is definitely trying to handle it If I'm right it surprises me that no one else has reported similar issues? Or am I totally wrong? Adam BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately. |
From: Mark P. <mar...@mo...> - 2019-02-19 21:54:19
|
Just to close the loop on this, I did resolve this by moving the Webware install to the same machine as the domain. Along the way I learned where I goofed on the redirect, so next time I should fare better. All’s well that ends well. > On Dec 28, 2018, at 2:06 PM, Christoph Zwerschke <ci...@on...> wrote: > > Am 28.12.2018 um 22:34 schrieb Mark Phillips: >> 3. http://www.mophilly.com/wk/MTI/ >> Result is a 301 if using Firefox. > > Just tried this and got a 302 that redirects me to the same address with https, which then yields a 501 (method not implemented), which is expected when using a GET request. After a POST request, I got a 200 with an error message indicating that I should use an XML-RPC client. > > The redirect from https to http seems to be cause by your Apache configuration (if not done by your Webware app) and that's the thing that confuses your old client. So you must tell your old client to use https instead of http, or change your Apache configuration so that it uses http. > > For security reasons, the former would be preferable. And you should also set ShowDebugInfoOnErrors = False in production in the AppConfig. > > -- Christoph > > > _______________________________________________ > Webware-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-devel |
From: Mark P. <mar...@mo...> - 2018-12-28 22:19:45
|
Thank you, Christoph. I will investigate and see what can be done. - Mark > On Dec 28, 2018, at 2:06 PM, Christoph Zwerschke <ci...@on...> wrote: > > Am 28.12.2018 um 22:34 schrieb Mark Phillips: >> 3. http://www.mophilly.com/wk/MTI/ >> Result is a 301 if using Firefox. > > Just tried this and got a 302 that redirects me to the same address with https, which then yields a 501 (method not implemented), which is expected when using a GET request. After a POST request, I got a 200 with an error message indicating that I should use an XML-RPC client. > > The redirect from https to http seems to be cause by your Apache configuration (if not done by your Webware app) and that's the thing that confuses your old client. So you must tell your old client to use https instead of http, or change your Apache configuration so that it uses http. > > For security reasons, the former would be preferable. And you should also set ShowDebugInfoOnErrors = False in production in the AppConfig. > > -- Christoph > > > _______________________________________________ > Webware-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-devel |
From: Christoph Z. <ci...@on...> - 2018-12-28 22:07:09
|
Am 28.12.2018 um 22:34 schrieb Mark Phillips: > 3. http://www.mophilly.com/wk/MTI/ > Result is a 301 if using Firefox. Just tried this and got a 302 that redirects me to the same address with https, which then yields a 501 (method not implemented), which is expected when using a GET request. After a POST request, I got a 200 with an error message indicating that I should use an XML-RPC client. The redirect from https to http seems to be cause by your Apache configuration (if not done by your Webware app) and that's the thing that confuses your old client. So you must tell your old client to use https instead of http, or change your Apache configuration so that it uses http. For security reasons, the former would be preferable. And you should also set ShowDebugInfoOnErrors = False in production in the AppConfig. -- Christoph |