New topic: 

2012R1 HTTPSocket Bug

<http://forums.realsoftware.com/viewtopic.php?t=45330>

         Page 1 of 1
   [ 1 post ]                 Previous topic | Next topic          Author  
Message        msssltd          Post subject: 2012R1 HTTPSocket BugPosted: Wed 
Sep 12, 2012 12:11 pm                                 
Joined: Fri Oct 28, 2005 7:05 am
Posts: 487
Location: Emsworth, UK                As mentioned on this thread, 
viewtopic.php?f=7&t=45282 
there is a bug in the HTTPSocket code shipped with 2012R1.  I said I would 
write up my own tests, so here you go. 


Warning:  Check the thread title.  If you happen to be reading this in 3 months 
or more, looking for a fix for your HTTPSocket problem, do not assume this is 
it.  Hopefully RS will fix this issue quickly.

For testing purposes, I used 2011R4.3 Enterprise (R4.3) and 2012R1 Enterprise 
(R1) on Windows 7 x 64.  As the original fault was in the Mac forum, I think we 
can safely assume the issue is across supported platforms.  Network sniffing 
was conducted with Wireshark 1.8 and the URI used to test was 
http://173.8.248.213:8086/weather.json 

Using HTTPSocket.Get(URI), the .PageReceived event fires in R4.3 but not in R1.

The first difference between R4.3 and R1 is the request sent to the server
R4.3 sends "GET /weather.json HTTP/1.0"
R1 sends "GET /weather.json HTTP/1.1"

At the HTTP layer this is what the server should respond with.  Hopefully you 
can follow my colorisation.

#0 Transfer-Encoding:chunked[CR][LF]
#1 <other headers>
#2 Accept-Ranges:bytes[CR][LF]
#3 [CR][LF]
#4 27f8
#5 {  "station":
#6 <data continues>
#7 }[CR][LF]
#8 0[CR][LF]
#9 [CR][LF]

Note the "27f8" and "0" characters I have emphasised in bold. These are the 
boundary delimiters for the data 'chunk' and are sent as ASCII. 0x27fe is the 
length of the chunk and 0[CR][LF] marks the end of the chunk.  Everything 
between these boundaries is the data. 

When .PageReceived fires in R4.3 the string passed as the "content" parameter, 
includes the chunk boundary marks.

Comparative testing

First of all, both R4.3 and R1 receive the headers just fine.

When calling .Get(URI) in either R4.3 or R1, the .ReceiveProgress event fires.  
The first observed difference is with the bytesReceived value passed to 
.ReceiveProgress 
R4.3, bytesReceived increments.
R1, bytesReceived is always 0.

As HTTPSocket is subclassed from TCPSocket, I assumed .ReceiveProgress was 
probably just .DataAvailable being re-raised after RS have done their 
processing.  To see what might be occurring , I populated the event and had a 
look at HTTPSocket.Lookahead.

Observed differences in .ProgressReceived behaviour;
newData parameter
R4.3, contains the new data
R1, always contains an empty string
 
HTTPSocket.Lookahead.LenB 
R4.3, is always 0.
R1, increments on subsequent calls.

R1, the .ProgressReceived event appears to be raised once too often, when there 
has been no changed to .Lookahead.LenB

So, what happens when "call me.Read(me.Lookahead.LenB)" is inserted in the R1 
.ReceiveProgress event handler?  
The bytesReceived parameter starts incrementing, the .PageReceived event fires 
with the "content" parameter populated.  However, unlike R4.3 the "content" 
parameter does not contains the chunk boundary markers.

It appears RS are failing to read the input buffer during DataAvailable, in 
some circumstances.  It's easy done.  Personally I would recommend waiting on 
RS to fix the issue, rather than shipping R1 code using the HTTPSocket or 
relying on my test results for production use.

I did some further fiddling, using .SendRequest("Get", URI) which seemed to 
indicate the un-necessary call to .ReceiveProgress might be wiping out the 
"content" buffer and leaving 7 bytes, including the 0 boundary mark, in the 
input buffer.  Those test were not conducted so methodically, are inconclusive 
and I won't be writing them up. 

Warning: On no account should you fiddle with .Lookahead and .Read in 
production code using the HTTPSocket.  It can cause  strange and unpredictable 
results.  On second thoughts please do, as it might generate enough calls to RS 
to convince them to provide some way to hide events and methods that are 
overriden in subclasses (TFIC).

HTH      
_________________
Yes it's me in the avatar  
                             Top             Display posts from previous: All 
posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost 
timeSubject AscendingDescending          Page 1 of 1
   [ 1 post ]      
-- 
Over 1500 classes with 29000 functions in one REALbasic plug-in collection. 
The Monkeybread Software Realbasic Plugin v9.3. 
http://www.monkeybreadsoftware.de/realbasic/plugins.shtml

[email protected]

Reply via email to