You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Noxx (JIRA)" <ji...@apache.org> on 2017/09/13 09:27:00 UTC
[jira] [Updated] (CXF-7502) Invalid or wrong dates returned
[ https://issues.apache.org/jira/browse/CXF-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noxx updated CXF-7502:
----------------------
Description:
I believe that the following is a CXF bug but as I am not really into the framework any help to isolate it or to report it to the correct tracker is really appreciated.
I am using the Python package "zeep" to generate a SOAP request, send it to my server and parse the response.
While handling dates within my application I came across the following issue and tried to reproduce it on an example:
Generate request on client side (you need to replace `<soap_client>` with your instance):
{code:none}
import datetime
data = datetime.date(1500, 3, 9)
end = datetime.date(1500, 3, 12)
with open("dateplotter.txt", "w") as file:
while data <= end:
returned = <soap_client>.date(data)
if returned:
returned = returned.date()
file.write("{} results in {}, diff: {}\n".format(data, returned, (returned-data).days))
else:
file.write("{} results in {}, diff: {}\n".format(data, returned, "--ERROR--"))
file.flush()
data = data + date
{code}
On the server side the incoming date object is returned without modification:
{code:java}
@WebMethod(action = "date")
public Date date(@WebParam(name="date") Date date) { return date; }
{code}
The content of the created file:
{code}
1500-03-09 results in 1500-02-28, diff: -9
1500-03-10 results in None, diff: --ERROR--
1500-03-11 results in 1500-03-01, diff: -10
1500-03-12 results in 1500-03-02, diff: -10
{code}
The request/response for the first roundtrip:
{code}
==>
http_headers: {'SOAPAction': '"date"', 'Content-Type': 'text/xml; charset=utf-8'}
operation: date(date: xsd:dateTime) -> return: xsd:dateTime
binding_options: {'address': 'https://mio/StepServer/service'}
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<ns0:date xmlns:ns0="http://step">
<date>1500-03-10T00:00:00</date>
</ns0:date>
</soap-env:Body>
</soap-env:Envelope>
==>
<==
http_headers: {'Keep-Alive': 'timeout=5, max=89', 'Content-Encoding': 'gzip', 'Connection': 'Keep-Alive', 'Content-Type': 'text/xml;charset=UTF-8', 'Server': 'Apache/2.4.18 (Ubuntu)', 'Date': 'Wed, 13 Sep 2017 08:52:55 GMT', 'Content-Length': '159', 'Vary': 'Accept-Encoding'}
operation: date(date: xsd:dateTime) -> return: xsd:dateTime
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:dateResponse xmlns:ns1="http://step">
<return xmlns:ns2="http://step">1500-02-28T00:00:00+01:00</return>
</ns1:dateResponse>
</soap:Body>
</soap:Envelope>
<==
{code}
The request/response for the second roundtrip which results in an hard error on the client side:
{code}
==>
http_headers: {'SOAPAction': '"date"', 'Content-Type': 'text/xml; charset=utf-8'}
binding_options: {'address': 'https://mio/StepServer/service'}
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<ns0:date xmlns:ns0="http://step">
<date>1500-03-11T00:00:00</date>
</ns0:date>
</soap-env:Body>
</soap-env:Envelope>
==>
<==
http_headers: {'Keep-Alive': 'timeout=5, max=88', 'Content-Encoding': 'gzip', 'Connection': 'Keep-Alive', 'Content-Type': 'text/xml;charset=UTF-8', 'Server': 'Apache/2.4.18 (Ubuntu)', 'Date': 'Wed, 13 Sep 2017 08:52:55 GMT', 'Content-Length': '159', 'Vary': 'Accept-Encoding'}
operation: date(date: xsd:dateTime) -> return: xsd:dateTime
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:dateResponse xmlns:ns1="http://step">
<return xmlns:ns2="http://step">1500-02-29T00:00:00+01:00</return>
</ns1:dateResponse>
</soap:Body>
</soap:Envelope>
<==
[2017-09-13 10:52:55,425][ ERROR][zeep.xsd.types.simple] Error during xml -> python translation
Traceback (most recent call last):
File "C:\Python34\lib\site-packages\zeep\xsd\types\simple.py", line 61, in parse_xmlelement
operation: date(date: xsd:dateTime) -> return: xsd:dateTime
return self.pythonvalue(xmlelement.text)
File "C:\Python34\lib\site-packages\zeep\xsd\types\builtins.py", line 136, in pythonvalue
return isodate.parse_datetime(value)
File "C:\Python34\lib\site-packages\isodate\isodatetime.py", line 55, in parse_datetime
tmpdate = parse_date(datestring)
File "C:\Python34\lib\site-packages\isodate\isodates.py", line 193, in parse_date
int(groups['month']) or 1, day)
ValueError: day is out of range for month
{code}
Remarks are:
* (!) The date is already changed when accessing it on the server side within the method so sth. happens already when parsing the incoming stream.
* The difference between the date sent to the server and the date which the client gets back is changing dependent of the date sent.
* A hard error occurs for a (non-existent) leap day.
* Within further tests I can reproduce:
** 1900-2100 the differences are 0 and no error occurs
** Dates near year 1 have a difference of 2 days (like 01.12.0001)
It seems there are two issues involved here:
* Handling leap years seems to be incorrect as 1500 is not a leap year and 29.02.1500 does not exist but is returned as a date.
* As no conversation or other handling of the incoming date is performed on the server side - why it has been changed? In the example above I would expect to get the same date back as I sent to the server independent of the value (except for invalid dates like the not-existing leap-day)
was:
I believe that the following is a CXF bug but as I am not really into the framework any help to isolate it or to report it to the correct tracker is really appreciated.
I am using the Python package "zeep" to generate a SOAP request, send it to my server and parse the response.
While handling dates within my application I came across the following issue and tried to reproduce it on an example:
Generate request on client side (you need to replace `<soap_client>` with your instance):
{code:none}
import datetime
data = datetime.date(1500, 3, 9)
end = datetime.date(1500, 3, 12)
with open("dateplotter.txt", "w") as file:
while data <= end:
returned = <soap_client>.date(data)
if returned:
returned = returned.date()
file.write("{} results in {}, diff: {}\n".format(data, returned, (returned-data).days))
else:
file.write("{} results in {}, diff: {}\n".format(data, returned, "--ERROR--"))
file.flush()
data = data + date
{code}
On the server side the incoming date object is returned without modification:
{code:java}
@WebMethod(action = "date")
public Date date(@WebParam(name="date") Date date) { return date; }
{code}
The content of the created file:
{code}
1500-03-09 results in 1500-02-28, diff: -9
1500-03-10 results in None, diff: --ERROR--
1500-03-11 results in 1500-03-01, diff: -10
1500-03-12 results in 1500-03-02, diff: -10
{code}
The request/response for the first roundtrip:
{code}
==>
http_headers: {'SOAPAction': '"date"', 'Content-Type': 'text/xml; charset=utf-8'}
operation: date(date: xsd:dateTime) -> return: xsd:dateTime
binding_options: {'address': 'https://mio/StepServer/service'}
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<ns0:date xmlns:ns0="http://step">
<date>1500-03-10T00:00:00</date>
</ns0:date>
</soap-env:Body>
</soap-env:Envelope>
==>
<==
http_headers: {'Keep-Alive': 'timeout=5, max=89', 'Content-Encoding': 'gzip', 'Connection': 'Keep-Alive', 'Content-Type': 'text/xml;charset=UTF-8', 'Server': 'Apache/2.4.18 (Ubuntu)', 'Date': 'Wed, 13 Sep 2017 08:52:55 GMT', 'Content-Length': '159', 'Vary': 'Accept-Encoding'}
operation: date(date: xsd:dateTime) -> return: xsd:dateTime
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:dateResponse xmlns:ns1="http://step">
<return xmlns:ns2="http://step">1500-02-28T00:00:00+01:00</return>
</ns1:dateResponse>
</soap:Body>
</soap:Envelope>
<==
{code}
The request/response for the second roundtrip which results in an hard error on the client side:
{code}
==>
http_headers: {'SOAPAction': '"date"', 'Content-Type': 'text/xml; charset=utf-8'}
binding_options: {'address': 'https://mio/StepServer/service'}
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<ns0:date xmlns:ns0="http://step">
<date>1500-03-11T00:00:00</date>
</ns0:date>
</soap-env:Body>
</soap-env:Envelope>
==>
<==
http_headers: {'Keep-Alive': 'timeout=5, max=88', 'Content-Encoding': 'gzip', 'Connection': 'Keep-Alive', 'Content-Type': 'text/xml;charset=UTF-8', 'Server': 'Apache/2.4.18 (Ubuntu)', 'Date': 'Wed, 13 Sep 2017 08:52:55 GMT', 'Content-Length': '159', 'Vary': 'Accept-Encoding'}
operation: date(date: xsd:dateTime) -> return: xsd:dateTime
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:dateResponse xmlns:ns1="http://step">
<return xmlns:ns2="http://step">1500-02-29T00:00:00+01:00</return>
</ns1:dateResponse>
</soap:Body>
</soap:Envelope>
<==
[2017-09-13 10:52:55,425][ ERROR][zeep.xsd.types.simple] Error during xml -> python translation
Traceback (most recent call last):
File "C:\Python34\lib\site-packages\zeep\xsd\types\simple.py", line 61, in parse_xmlelement
operation: date(date: xsd:dateTime) -> return: xsd:dateTime
return self.pythonvalue(xmlelement.text)
File "C:\Python34\lib\site-packages\zeep\xsd\types\builtins.py", line 136, in pythonvalue
return isodate.parse_datetime(value)
File "C:\Python34\lib\site-packages\isodate\isodatetime.py", line 55, in parse_datetime
tmpdate = parse_date(datestring)
File "C:\Python34\lib\site-packages\isodate\isodates.py", line 193, in parse_date
int(groups['month']) or 1, day)
ValueError: day is out of range for month
{code}
Remarks are:
* The difference between the date sent to the server and the date which the client gets back is changing dependent of the date sent.
* A hard error occurs for a (non-existent) leap day.
* Within further tests I can reproduce:
** 1900-2100 the differences are 0 and no error occurs
** Dates near year 1 have a difference of 2 days (like 01.12.0001)
It seems there are two issues involved here:
* Handling leap years seems to be incorrect as 1500 is not a leap year and 29.02.1500 does not exist but is returned as a date.
* As no conversation or other handling of the incoming date is performed on the server side - why it has been changed? In the example above I would expect to get the same date back as I sent to the server independent of the value (except for invalid dates like the not-existing leap-day)
> Invalid or wrong dates returned
> -------------------------------
>
> Key: CXF-7502
> URL: https://issues.apache.org/jira/browse/CXF-7502
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.1.12
> Environment: Server on Linux/Ubuntu 16.04 with Tomcat 8.5.12 and CXF 3.1.12
> Client on Windows 7 64bit with Python3.4 and Zeep 2.2.0
> Reporter: Noxx
>
> I believe that the following is a CXF bug but as I am not really into the framework any help to isolate it or to report it to the correct tracker is really appreciated.
> I am using the Python package "zeep" to generate a SOAP request, send it to my server and parse the response.
> While handling dates within my application I came across the following issue and tried to reproduce it on an example:
> Generate request on client side (you need to replace `<soap_client>` with your instance):
> {code:none}
> import datetime
> data = datetime.date(1500, 3, 9)
> end = datetime.date(1500, 3, 12)
> with open("dateplotter.txt", "w") as file:
> while data <= end:
> returned = <soap_client>.date(data)
> if returned:
> returned = returned.date()
> file.write("{} results in {}, diff: {}\n".format(data, returned, (returned-data).days))
> else:
> file.write("{} results in {}, diff: {}\n".format(data, returned, "--ERROR--"))
> file.flush()
> data = data + date
> {code}
> On the server side the incoming date object is returned without modification:
> {code:java}
> @WebMethod(action = "date")
> public Date date(@WebParam(name="date") Date date) { return date; }
> {code}
> The content of the created file:
> {code}
> 1500-03-09 results in 1500-02-28, diff: -9
> 1500-03-10 results in None, diff: --ERROR--
> 1500-03-11 results in 1500-03-01, diff: -10
> 1500-03-12 results in 1500-03-02, diff: -10
> {code}
> The request/response for the first roundtrip:
> {code}
> ==>
> http_headers: {'SOAPAction': '"date"', 'Content-Type': 'text/xml; charset=utf-8'}
> operation: date(date: xsd:dateTime) -> return: xsd:dateTime
> binding_options: {'address': 'https://mio/StepServer/service'}
> <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
> <soap-env:Body>
> <ns0:date xmlns:ns0="http://step">
> <date>1500-03-10T00:00:00</date>
> </ns0:date>
> </soap-env:Body>
> </soap-env:Envelope>
> ==>
> <==
> http_headers: {'Keep-Alive': 'timeout=5, max=89', 'Content-Encoding': 'gzip', 'Connection': 'Keep-Alive', 'Content-Type': 'text/xml;charset=UTF-8', 'Server': 'Apache/2.4.18 (Ubuntu)', 'Date': 'Wed, 13 Sep 2017 08:52:55 GMT', 'Content-Length': '159', 'Vary': 'Accept-Encoding'}
> operation: date(date: xsd:dateTime) -> return: xsd:dateTime
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <ns1:dateResponse xmlns:ns1="http://step">
> <return xmlns:ns2="http://step">1500-02-28T00:00:00+01:00</return>
> </ns1:dateResponse>
> </soap:Body>
> </soap:Envelope>
> <==
> {code}
> The request/response for the second roundtrip which results in an hard error on the client side:
> {code}
> ==>
> http_headers: {'SOAPAction': '"date"', 'Content-Type': 'text/xml; charset=utf-8'}
> binding_options: {'address': 'https://mio/StepServer/service'}
> <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
> <soap-env:Body>
> <ns0:date xmlns:ns0="http://step">
> <date>1500-03-11T00:00:00</date>
> </ns0:date>
> </soap-env:Body>
> </soap-env:Envelope>
> ==>
> <==
> http_headers: {'Keep-Alive': 'timeout=5, max=88', 'Content-Encoding': 'gzip', 'Connection': 'Keep-Alive', 'Content-Type': 'text/xml;charset=UTF-8', 'Server': 'Apache/2.4.18 (Ubuntu)', 'Date': 'Wed, 13 Sep 2017 08:52:55 GMT', 'Content-Length': '159', 'Vary': 'Accept-Encoding'}
> operation: date(date: xsd:dateTime) -> return: xsd:dateTime
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <ns1:dateResponse xmlns:ns1="http://step">
> <return xmlns:ns2="http://step">1500-02-29T00:00:00+01:00</return>
> </ns1:dateResponse>
> </soap:Body>
> </soap:Envelope>
> <==
> [2017-09-13 10:52:55,425][ ERROR][zeep.xsd.types.simple] Error during xml -> python translation
> Traceback (most recent call last):
> File "C:\Python34\lib\site-packages\zeep\xsd\types\simple.py", line 61, in parse_xmlelement
> operation: date(date: xsd:dateTime) -> return: xsd:dateTime
> return self.pythonvalue(xmlelement.text)
> File "C:\Python34\lib\site-packages\zeep\xsd\types\builtins.py", line 136, in pythonvalue
> return isodate.parse_datetime(value)
> File "C:\Python34\lib\site-packages\isodate\isodatetime.py", line 55, in parse_datetime
> tmpdate = parse_date(datestring)
> File "C:\Python34\lib\site-packages\isodate\isodates.py", line 193, in parse_date
> int(groups['month']) or 1, day)
> ValueError: day is out of range for month
> {code}
> Remarks are:
> * (!) The date is already changed when accessing it on the server side within the method so sth. happens already when parsing the incoming stream.
> * The difference between the date sent to the server and the date which the client gets back is changing dependent of the date sent.
> * A hard error occurs for a (non-existent) leap day.
> * Within further tests I can reproduce:
> ** 1900-2100 the differences are 0 and no error occurs
> ** Dates near year 1 have a difference of 2 days (like 01.12.0001)
> It seems there are two issues involved here:
> * Handling leap years seems to be incorrect as 1500 is not a leap year and 29.02.1500 does not exist but is returned as a date.
> * As no conversation or other handling of the incoming date is performed on the server side - why it has been changed? In the example above I would expect to get the same date back as I sent to the server independent of the value (except for invalid dates like the not-existing leap-day)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)