Re: [Themis-dev] Latest HTTP changes

[Raymond R. <ra...@ba...>]

On 02/10/2011 01:30 PM, Mark Hellegers wrote:
>> Hi all,
>>   I just want to take a moment to report on my latest tweak(s) to
>> the HTTP add-on. Mark has mentioned on a couple of occasions that the
>> broadcasts that the HTML parser sometimes receives doesn't contain the
>> content's MIME type, in particular when loading the page a second time
>> within any particular Themis session. Due to the nature of the issue, he
>> thought it might be an issue with the cache system and asked me to
>> investigate it.
>>
>>   You'll probably guess correctly, because of the email subject, that the
>> problem was actually in HTTP. Basically, the HTTP add-on was only adding
>> the mime type to the broadcasts when the page wasn't found in cache or
>> the server returned an updated version of the content. (A 200 level HTTP
>> response rather than a 304 Not Modified response.) I think I deliberately
>> did this, years ago, because the content type must not have changed if
>> the server is returning a not modified response. Nonetheless, I didn't
>> foresee that this would add further complications to other parts of the
>> app, even though it would be possible to obtain the appropriate
>> information directly from the cache system. So, I'm now including the
>> MIME type in just about all "loading progress" broadcasts from HTTP,
>> which should get the HTML parser working properly. My apologies for
>> earlier my earlier weirdness... ;-)
> Hi Raymond,
>
> I had some time to test it today and found that the html parser is still
> not parsing the file again, but now it is going wrong in another part.
> It now sees that the document is supported and tries to parse it. But
> before it starts the actual parse, it wants to get the data from the cache
> and that fails.
> I think it has something to do that reading from the cache for the second
> time with the same user token still has the pointer at the end of the
> file, so there is nothing to read. If that is correct, is there a way to
> reset the pointer to the start?
> I couldn't find it with a quick look at the cache header.
>
> Mark
>
Sorry for taking so long to respond to this, I've been busy with school. 
I got your IM this morning and decided to work towards resolving this today.

Now, at first I thought I made a bad mistake when I originally wrote the 
cache system years ago, and didn't implement a way to keep track of the 
read positions in cache objects for each given cache user, but 
fortunately, as I was implementing such a system, I realized that I 
hadn't overlooked it. Looking through it and re-reading your message, I 
discovered that the system didn't support any direct method for the 
cache user to start reading at an earlier position in the file, for 
instance if it needed to back up and start reading from the beginning. 
So, I've modified the CachePlug::Read() function to include two new 
optional parameters: boolean resetReadPosition, and off_t newReadPosition.

These both use default arguments of false and 0L respectively, so all 
the code that currently reads from the cache system will continue to 
work properly unmodified. However, if you have need to start reading a 
file from the beginning again, you can set the resetReadPosition 
parameter to true, which will allow you to either specifically set the 
new read position (newReadPosition), or to let it default to 0, which is 
the beginning of the file.

Hopefully this solution is an adequate one, let me know if not.

Raymond

-- 
Raymond Rodgers
http://www.badlucksoft.com/
http://anevilgeni.us/