|
HoTTProxy Known Bugs and To-Do List
Bugs
All software has bugs. Some bugs you know about, and some you don't. I've tried to hold off releasing HoTTProxy until
all of the bugs I knew about were fixed. That of course leaves the ones I don't know about which I'm sure will get
pointed out by someone at some point. If you find a bug, or think you've found a bug, post it on the support forum - please
don't e-mail it to me. There are also some things that you could call bugs that are actually just things I
haven't had a chance to write yet. Those items I am going to call the "to-do" items.
To-Do Items
Like the "bugs" list, I tried to get the really big items off the To-Do list before releasing the code. That
said, the code is to the point where the stuff left on the to-do list is minor enough that you'd probably rather have
the program to play with than keep waiting for the last of the small stuff. If you come up with a nifty feature that you
think HoTTProxy needs, please post it on the discussion forum so we can all chat about it.
Remove expired proxy cookies from disk - Right now, if a stored proxy cookie is expired
HoTTProxy will not send it to the web server (which is the correct thing to do). However, the
expired cookie sits essentially forever in the .cookie file that it is in. If a new, unexpired cookie
by the same name is received, the old expired cookie will be replaced with the new one (which
is again, correct). This is really just a housekeeping issue. Once a cookie is expired it should be
removed from the .cookie file the next time that cookie file is rewritten. If all of the cookies in a
given .cookie file expire, then the file should be deleted. Do a "filefree" check before writing .cookies files - When an updated cookie is
received (new value for an old cookie or a net new cookie), HoTTProxy rewrites the .cookies file
that corresponds to the domain restriction for that cookie. While unlikely, since HoTTProxy is
multi-threaded, it is possible that two different threads will receive an updated cookie for the
same .cookies file, and both threads may try to write to that .cookies file at the same time. If this
happened, the .cookies file might get messed up. This is a remote possibility but is easy to fix
when I get around to it. What to do with the log - HoTTProxy keeps a basic log of requests that it handles (HoTTProxyLog.txt).
Although this log accumulates relatively little data, eventually it could grow quite large (though I think
it would take a long time). I'm inclined to leave this bit of maintenance up to the user and just let them
delete the log whenever it gets bigger than they'd like. Any other solution runs the risk of dumping
log entries that the user might want. Suggestions? Code for CookiePassthru and SetCookiePassthru - Despite having entries in the configuration file, and
being mentioned in the documentation, the CookiePassthru and SetCookiePassthru parameters presently don't do
anything. They are intended to allow the user to de-isolate the cookies of a cookie-aware browser
that uses the proxy server. Presently, HoTTProxy handles all of the cookie work except any cookies
that might be sent or received inside an SSL session (which HoTTProxy cannot "see"). If the browser
has any cookies that it tries to send, HoTTProxy kills them and inserts only the cookies that HoTTProxy has
for the particular website being called. Conversely, when a website sends cookies, HoTTProxy stores those
cookies, and then removes the 'Set-Cookie' headers before forwarding the response to the browser. It should be
noted that for most, if not all, wireless devices, this action is meaningless since those devices typically
do not support cookies (and therefore have none to send and ignore any received). Where this would matter
would be in the case of someone using a personal computer based browser, to access the Internet through HoTTProxy.
Here the browser is "cookie aware" and very well may try to send cookies of its own. Since
HoTTProxy stores cookies "by user", assuming the same user used HoTTProxy via multiple devices,
you could easily end up in a situation where the cookies on a cookie-aware browser conflicted with the
cookies stored by HoTTProxy. It was for this reason that HoTTProxy was written to isolate the browser from
all cookie handling. This has interesting benefits. If you are using HoTTProxy on one device, and set certain
preferences for several websites, and then later use another device, also through HoTTProxy, you will effectively
"have" the same set of cookies since HoTTProxy is handling them for you (instead of the device).
Therefore your preferences would be consistent across all devices that were using HoTTProxy. In any event,
some day I'll probably make these two options do what I originally intended, but since I don't see the real
need, someone will probably have to explain why they really need it before I do. Cool add-on utilities - One of the design requirements for HoTTProxy was that everything be controlled
by text files (configuration, user accounts, storage of cookies, etc.) to simplify creation of nifty utilities
for HoTTProxy. Some ideas: a tool to view and edit the stored proxy cookies, a GUI for creating and editing
user accounts, a tool for viewing the log, etc. I've actually written some of these in some form or another, but
they are all web based, and in order to be useful without requiring the user to also have a web server, HTTP daemon
support needs to be added to HoTTProxy. This is perfectly do-able, but is not a minor undertaking. Need to write a manual - I'm not sure when, if ever, I'll do this since everything is subject to
change, and since I have put so much time into the website. Maybe someone more interested in the task will
volunteer to put a manual together using the information from the website.
|