🚀 go-pugleaf

Remy Lebeau (TeamB) escreveu:
> You don't have to do that, though.  If you implement it properly in
> the first place, then the code will automatically adapt to whatever
> content it receives, so you won't have to re-write the code each time
> a change occurs.
> 

I know this. I know that I must be this ia very different aproach to 
make my life more easy. But for now, the time difference that I get if I 
verify every token on the header is not possible to take...

If I find a way to do the code even more fast, I'll do it, even if this 
will turn the code more problematic. In this unic and exclusive app, I 
need this.

  > Chunking is a server-side configuration.  Many systems don't use
> chunked transfers.  It actually produces more overhead than sending
> the raw data as-is instead.  Chunking tends to be used only on systems
> that support partial downloads, such as for resuming broken transfers.
> Not all systems support that, though.

Yes... I see. But the page is chunked. I verify the header. And I 
executed the code. The page never comes entire. It comes a first part, 
that contains the header and an hexa that say the number of bytes to 
read. Then on the next loop, I receive a new chunk with a new hexa that 
says the length of the new chunk, a third time this occour and on the 
fourth, the signal that the send of chunked data ends is present 
"0\r\n\r\n". So I quit the loop because there not more data to read...
Is this wrong? The last bytes of the last chunk are not "0\r\n\r\n"?

> 
>> Oh...
>> But I'm stopping :)
> 
> But not as quickly as you could be.  You seem to be very fond of
> writing fast running code, but you are not handling the HTTP responses
> in a way that allows you to exit as soon as the response is finished.
> You are sitting there waiting for a timeout that you do not need to
> wait for if you take the true data length into account properly like
> the RFCs say to do.
> 

And how to do that?

>> If you look at the code, you'll see this:
> 
> Which is still the completely wrong thing to do.
> 

And what I must to do?

> But you are not reading the individual chunks properly at all.  Which
> is why you are getting into a scenerio that relies on a waiting loop
> to time out.
> 
I don't getting on a wauting loop... I don't understand... What you mean?

Eduardo.