AbuNaifAlharbi / openhab

Automatically exported from code.google.com/p/openhab
GNU General Public License v3.0
0 stars 0 forks source link

Http long polling went wrong in 1.3.0 snapshot #506

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Suddenly REST API switched to chunk transfer encoding of responses. Probably 
this happened because some of the underlaying libraries were upgraded. Probably 
atmosphere. The result is incorrect chunk response. In chunk encoding server is 
sending responses in parts, providing length of every part prior to sending it. 
The problem is that immediately after making a request openhab sends some bogus 
chunk consisting of 32 \20 symbols with incorrect chunk length (2001 hexdecimal 
which should mean 8193 bytes) which causes most of http clients to raise a 
protocol exception and close connection. While opening connection in manual 
mode (telnet) I noticed that when some change happens to requested sitemap 
page, after bogus chunk, openhab finally will respond with sitemap with correct 
chunk length. So this completely breaks down long-polling until resolved :-(

Original issue reported on code.google.com by belovic...@gmail.com on 5 Nov 2013 at 12:27

GoogleCodeExporter commented 9 years ago
Moreover, when making an HTTP 1.0 request which blocks chunk encoding, there 
are still those bogus 32 \20 symbols which arrive immediately after header, and 
then request is paused until something changes in sitemap. Then normal data 
arrives when some changes happen.

Original comment by belovic...@gmail.com on 5 Nov 2013 at 12:30

GoogleCodeExporter commented 9 years ago
Is this solved by the latest Atmosphere changes?

Original comment by kai.openhab on 5 Dec 2013 at 10:28

GoogleCodeExporter commented 9 years ago
Assuming that it is, I close this issue.

Original comment by kai.openhab on 7 Dec 2013 at 8:52