Luci - changelog


 - Wednesday, July 5th 2006 at 1:04 p.m. - luci/1.4


=head1 TO BE ASSESSED - (for future release)
 - what about one instance that calls another that calls back, etc...
   we've cleaned most of this up, but would it be easier to recognize 
   this with mod_perl and/or sessions?
 - what about mod_perl
   would this allow a throttle of sorts so we could limit requests from 
 - look at providing page summary option
   see feature request #1063126
 - add test for proper configuration 
   could probably check for required modules
   test this with bad settings.  we may need to check for tmpl files too
   not sure if this is necessary yet.  we have marked what needs to be
   set in the conf.  if luci grows much larger, this may become a 
 - add feature to allow hrs? (see: Lynx)
 - try commenting out allowed ext on the default url
   need to look at checking extensions on index files (hidden)
   the only thing that's messed up here is if someone actually had their server
   setup to serve something other than one of the extensions in the allowed list
   as the default index.  ex: 'DirectoryIndex index.pdf' in the apache config
   would force luci to attempt a parse on index.pdf.
 - what about download of different mime types? (ie. from cgi - ex: vcard) 
 - 'graphical version' link in framed page should return entire frameset
 - should provide other options for link delimiting
 - add functionality for enctype='multipart/form-data' (uploading)
   this will require a repository for luci to temporarily store files 
   on the server
 - should there be a logout feature? 
   (ie. wrap in a template?) for htaccess (401s)
 - look at other protocols: ftp/gopher/etc...


Wednesday, July 5th 2006 at 1:04 p.m. - luci/1.4

 - document qmeta
 - fix url provided is not valid etc...
   this has been updated
 - debug is available for luci.cgi, should we have a global debug that can 
   be used for the libraries?  should all of luci have debugging?
   took this out of the TBA list seeing as the functionality has been added
 - _denylist/_allowlist 
   see config for rules/conventions
   note: you can use the allowlist/denylist settings together to allow 
   most files, but not all from a specific domain
 - added _denylist feature
 - allowed_domains renamed _allowlist
 - under apache 2, we noticed luci having difficulties with path_info
   when the request for luci is already a path_info request.  the solution
   was to simply rebuild the original url, then pull path_info from there
        my $path_info = ($config->{system}->{apache_2}=~/true/i)
        ? URI::URL->new($ENV{REQUEST_URI}, $ENV{SERVER_URL})->abs->as_string
        : CGI::url(-path_info => 1);  
 - added default value to $sep variable

Tuesday, May 30th 2006 at 11:45 a.m. - luci/1.3

 - wait for john's final version of his MS Environment (2003) doc
   update the website doc when it arrives
 - making use of config feature to allow deeper debugging
   ie. in the modules
 - there is an issue with multi-checkboxes in post request
   multi-checkboxes were posting null delimited and are now cleaned up and 
   sent as distinct entries
 - ok we're done with findbin and mod @INC directly
   use vars qw($path $sep);
   BEGIN { # see changelog
        $0=~s/^(.*)(\/|\\)// and $path=$1 or $path='.';
        $sep = $2;
        unshift @INC, $path.$sep."lib";
   this allows a little more flexibility, passes taint and works on MS
 - added a config setting for apache 2  
   note: default apache 2 install does not recognize path_info as a 
   separate entity, and returns the entire url regardless   
 - update MS 2000 docs
 - add MS 2003 docs - will require testing
 - perlis.dll
   john's document to provide instruction's based on perlis.dll   
 - what about one instance that calls another that calls back, etc...
   if two instances simply reference each other via path_info
   this is clean.
   if path_info =~ app_root_url, luci will spawn (self recursing) 
   this is fixed.  we fail over to default_target
   if two instances reference each other via default_target
   there is a possibility of infinite loop here
   this is fixed.  
   1. since this is recursive, we test for app_root_url in path_info
   2. on occurrence, we intend to swap for default_target
   3. if default_target == app_root_url... fatal error
 - test MS 2003 https 
 - update docs wrt LUCI_CONF and FindBin
 - update cvs link - check all links
   clean up links to yourdomain.  they should not href
 - add john to contrib
 - add john's doc to the website
 - use lib (($FindBin::Bin.'/lib')=~/^(.*)$/); 
   solution ported from FindBin::libs (find_libs subroutine)
   see source:
   as per doc:
   when running taint mode (-T), '.' is removed from @INC
   we need '.' in order to reference our lib which is at './lib'
   we could set lib manually
   ex: use lib './lib'
   unfortunately, this is not portable.  Under the MS environment (2003), 
   this simply will not work, and we would like to avoid having users edit 
   the executables directly.  the solution is to use FindBin, which will 
   produce cwd.  Unfortunately, FindBin will not pass the taint check when 
   used in this context because $FindBin::Bin is tainted.  the solution is to 
 - again have corrected a bug found in the attempt to pull a proper path_info
   as opposed to failing, we now correct the error by setting path_info 
   manually if it is not provided.  this fix also rectifies the error found 
   under MS where an incorrect value is supplied as path_info when no path 
   info is supplied.  if app_root_url is not set correctly in the config, 
   the user will notice that links will not work properly.  after turning on
   debug, it may be noted that app_root_url under config does not match the 
   base url that can be viewed at the top of a browser window. 
 - cleaned up debug settings
   1 dumps vars/env/config
   2 dumps object data also
 - converted index.cgi redirect to use CGI::redirect 
   simple location: print would not work 
 - now making use of FindBin for locating luci.conf.cgi
   this was required as a MS fix
 - added feature that allows toggle of heading level display
   see conf
 - modified the CBC specification in  someone ran into
   problems where the iv was required even though prepend_iv was set
   false.  anyway, these options were removed, and having header set
   as 'salt' should allow CBC to generate the cipher key and the iv
   from the passphrase (in our case, the cryptkey)
 - added feature <span class="luciignore"> ignore this </span>
   added documentation for this feature
 - update sourceforge admin 
   added screenshots
   removed forum and patch tracker
   updated all tracker items to correspond with
   cleaned up current tracker items 
 - look at TBA 
   some of this was completed.
 - should output follow the xhtml standard? 
   added use of module HTML::Entities for proper URL encoding
   most other errors cannot easily be corrected by luci.  for example, it
   is a requirement that the id attribute value begin with a character and
   not a digit.  if it is the case that the page you are requesting does 
   not follow the proper convention, it will continue to fail the xhtml 
   standard as luci does not attempt to correct a misspelling of the id value.
   also found a spelling error in the templates wrt </tbody> that was causing
   an xhtml error with open tag. 
   note: luci does a pretty good job at cleaning up the html, in turn possibly
   making a site 'more' xhtml compliant 
 - add DEBUGging feature (for dev) 
   would require levels 
   put DEBUG in conf (use Data::Dumper)
   to date, debugging has been ad-hoc
   this was done long ago.  there is also a TBA on debug in modules
 - documentation could use a review
   this is done.  docs look good
 - look at possible ip forwarding
   the idea here is that luci would represent herself with the ip of the 
   client, as opposed to the ip of her host.
   we spent some time researching the possibility of forwarding the user ip 
   through luci, but we realize this will definitely introduce many more 
   challenges, and does not appear possible.  for one, we believe ip spoofing 
   (which is somewhat indirectly the requirement here) may be considered 
   illegal, although this may be somewhat dependent on the context.  on 
   another note, even if we manage to get it working, it should be noted that 
   ip communication is a two way street.  ie. responses are returned to the 
   requesting ip, and if luci is to represent herself with the client ip, she
   will therefore not receive the response, as it will be returned to the 
 - we had a request wrt cookie proxying. some substantial discussion 
   came from this, and our decision was to avoid implementing this feature
   for several reasons.  some info follows:
   - the request:
        From the LUCI documentation, it says that LUCI "stores all cookies that
        the user comes across in one single cookie."  Does this mean that users
        that create cookies during text-only will not be able to use those 
        cookies in graphical view?  If so, is there a workaround?
   - our response:
        Even though it 'may' be possible to have luci pass a cookie from  to your browser, adding this functionality would appear  
        quite confusing to a client, seeing as luci cannot do the reverse;  
        ie. provide cookies that you have set in your browser via graphical  
        surfing to  The other issue we would have to take into  
        consideration if we were to consider adding this feature is that we  
        are really unsure as to whether or not luci would be able to set a  
        cookie in the client browser that belongs to and not   Please refer to section 4.3.2 Rejecting Cookies  
        (rfc2109) as per W3C:
        "a user agent rejects a cookie if
        * The value for the request-host does not domain-match the Domain
        So, in other words, a cookie with domain "" passed to
        the browser via luci hosted on "" will be rejected.
        Also, we can't make the cookies be given from graphical to luci properly
        because of the path var in cookies. The browser will call luci  
        from its path, and the cookies for the requested page (which presumably 
        is in a different path) will not be sent to the page, because luci 
        never got them from the client (unless the site sets cookies on a '/'
        path).  This makes the transition from graphical browsing cookies to 
        luci browsing cookies impossible.
        Going from luci browsing cookies to client graphical cookies is  
        possible for sure on the same domain, but is pointless in reality if 
        the other direction doesn't work, and even more pointless for external  
        domains (if setting cookies for external domains actually works)
        So to avoid the confusion that could quite possibly come from this, 
        we've decided against implementation.  If a strong case arises, we
        may revist this request.
 - what about converting luci.conf to luci.cgi or or
   this will require docs in luci.cgi pod
   done.  we've changed it to luci.conf.cgi. docs now reference the new
   configuration file name
 - removed the binmode STDOUT utf8 fix.  it was messing up obviously simple
 - cleanup warnings (ie. -w) 
   I've cleaned up some... maybe a complete cleanup for 1.4.  There aren't
   that many warnings, and alot are associated with external modules
 - use of uninitialized value in concatenation (.) or string 
        at lib/ line 64.
 - use of uninitialized value in pattern match (m//) 
        at lib/ line 130.  
 - use of uninitialized value in pattern match (m//) 
        at lib/ line 70
 - use of uninitialized value in concatenation (.) or string 
        at lib/ line 312.       
 - eval { binmode STDOUT, ":utf8" } fixes wide character in print error
 - check on allowed domain and/or * before completing the upgrade
   there was a bug associated with this regex where if a user specified, as allowed, would also be allowed
   this has been fixed
 - cleanup lists from conf.  set them up as hash lookup (ex: ignore_tag)
   decided against this.  current method of use appears to be the most 
 - consider removing web content from luci package
   the following was decided:
   1. remove the INSTALL.txt
   2. move README.txt to luci root directory.  update it to point at
   3. move LICENSE.txt to luci root 
   4. remove docs folder from future distributions
   the idea here is that the documentation we link to will always be the 
   most recent, namely that located at the sourceforge site    
 - issues wrt too many concurrent invocations of luci
   in our environment, where luci is hosted without any url restriction 
   we have seen instances where googlebot will attempt to index the 
   internet via luci, in turn saturating any available resources on the
   host, denying access to all other requests
   solution: performance test luci and see what happens
   this was done using httperf and autobench
   results show that all luci invocations start up and releases appropriately 
   without any relation to the number of luci processes spawned.
   the real issue is that crawling engines such as googlebot 
   recognize sites via luci as non-existent in their index, and so
   begin indexing, even though they should be considered a duplicate.
   this should be a non-issue for smaller sites that use the 
   allowed_domain directive in the luci.conf file, but for larger
   sites, or those that do not make use of the allowed_domain directive,
   this can be a problem.  for example, the googlebot engine is not only 
   fast, but runs in a distributed environment, and if it begins spidering
   the internet via some luci instance, could bombard your server, in turn
   bringing it to its knees.
   for information on googlebot, see:
   final solution:
   as per the googlebot documentation,  we went ahead and added both the 
   robots.txt entries and the meta nofollow pragma necessary to have 
   crawler engines ignore luci.  seeing as this affected us directly, we also
   decided to contact google to ensure we took the proper route, and so
   google checked and confirmed our robots.txt was setup correctly.
   without the robots.txt entry, the nofollow pragma should be enough to 
   ensure a crawler engine does not proceed any further than the initial 
   page served via luci.  with the robots.txt entry, your luci instance 
   shouldn't be indexed whatsoever.
   information wrt the proper content of a robots.txt file will be provided
   with the install documentation, and the appropriate meta tags will be 
   included by default in the header of those templates where it is necessary
 - clean up use statements
 - added config ref to the UtilFunctions object
 - add disclaimer toggle option to config
   freed up is_internal for its use (see is_allowed)
   we compare is_internal vs. user setting in conf
   added an override that forces disclaimer no matter the domain
   added disclaimer template
   see luci.conf:
   possible values:
   external - disclaimer will only display on pages external
   force - disclaimer will always display
   off - disclaimer is not displayed (default)    
 - added _is_internal to displayer object 
   required for disclaimer option
 - fix pod linking errors and clean up documentation
 - 180s default timeout appears to be too much... 
   when luci takes off on a bad ua request, (to be fixed separately), 
   it will spawn some number of processes which can be limited
   with a decent setting here. the initial setting has been changed to 16s
 - can we keep luci from spawning multiple processes?
   it looks as though luci will call herself if app_root_url is not set
   correctly.  hence luci spawning is actually luci calling herself, in
   turn calling herself... etc...
   this has been fixed.  we now test that the substitution in parse_target
   of luci.cgi actually acquires path_info, and fail otherwise
 - as it was required for the path_info error to die, the error routine in
   UtilFunctions can now be overloaded with an error code, and will force the
   application to die

Monday, May 16th 2005 at 1:26 p.m. - luci/1.2

 - PageParser error on base target pointing at _top/etc...
   fixed.  ignore target 
 - fix size sort on settings page
   done. went back to <=> and use integer priority in luci.conf
 - link delimiter should work on all links including luci stock
 - add cfm extension for parsing
 - need to test ssl on IIS
 - include Kyle's documenation 
   done. Kyle's docs have been merged 
 - add DEBUG
   done.  very broad debugging has been implemented and can be
   configured from luci.conf
 - https test bug
   when testing ssl in luci.cgi, we now check app_root_url as opposed
   to testing the SERVER_URL environment variable in an attempt to 
   reduce environment dependencies.  
 - add Scott to Acknowledgements
 - thanks to unbsj its 
 - add platform specific section
 - I tried to get luci under MS Environment to not require user
   modification of the 'use lib' and LUCI_CONF constant, but  
   cannot seem to get around the Cwd/FindBin taint problems.
   instructions for MS users will be added 
 - 'use lib' and LUCI_CONF ref now use single quotes.  
   double quotes were causing issues in the MS environment
 - pod all files
   done long ago. we need to complete the documentation.
 - provide logo 
   done long ago - removed from tba.
 - removed the $ENV{SERVER_URL} dependency, and now check SSL 
   against $config->{app_root_url};
 - need to upgrade the pod in luci.cgi to reflect the new 
   Twofish_PP package requirement and remove Shark
 - switched to the Twofish_PP algorithm which seems to be available to 
   both UNIX and ActivePerl ( upgrade)
   Shark was not available from the ActivePerl Package Manager at the 
   time of this writing.  Although it could probably be compiled for 
   use under ActivePerl, it was decided we would use the one that is 
   immediately available to the package manager.
 - removed the use of $ENV{PATH_INFO}: now using CGI::url and 
   pulling path_info manually.  this seems to have fixed the PATH_INFO
   environment variable problem in the MS Environment, and 
   continues to work properly under UNIX.
 - css the pod
   decided against this.  we like pod
 - MS Environment: Luci seems to be able to parse herself.  Makes a mess.
   fixed.  In luci.cgi, clean url before self parse test
 - MS Environment trims double slashes in path_info  
   fix added in luci.cgi

Tuesday, October 19th 2004 at 1:30 p.m. - luci/1.1

 - display settings page is carrying meta refresh from target  
   fixed.  settings page no longer carries refresh from target 
 - malformed meta refresh tag does not work properly.   
   fixed.  luci will now allow for (reasonably) bad content and will 
   correct accordingly
 - updated author info in all pods
 - removed BUG info from pod.  BUG info hosted on sourceforge.
 - should be a space between 'Undescribed[image]' for alt tag images
   fixed.  Also changed [image] to [ALTTEXT]
 - update luci.conf with new version information
 - inconsistent display of settings on display settings page 
   fixed.  using cmp instead of <=> and sort for color schemes
 - fix wording - luci error page: 'request that they host Luci in a "secured"'
 - inconsistent name struct for settings: ie. stlye settings::display settings
   done. both are now 'display settings'

Tuesday, September 28th 2004 at 3:30 p.m. - luci/1.0

 - add link to luci page where version is displayed 
 - change 'text only' to 'accessible version' in main docs
 - add new luci logo, and add image sizes, alt, etc...
   30x30 and 150x150
 - change NAME in luci pod -> Luci - (href)UNB's eLUCIdator  
 - link ref to UNB, and add Canada
 - add link to UNB in related links 
 - add UNB Webteam to acknowledgements with email and web address
 - remove empty <tfoot> tags from templates
 - cleanup use statements
 - TM application references (if required)
 - comment the config 
 - install
 - required modules
 - why the rewirite?
 - write something so that Luci automatically grabs the correct url.
   done. see index.cgi in distribution root
 - explain what needs to be done to hide the conf (if this is needed)
 - force fail on https request when luci hosted under http

Monday, September 13th 2004 at 4:30 p.m. - luci/0.99b

 - source_delimit was causing problems where inline tags such as <b>, <i> 
   etc... were embeded within a string. We've added an ignore_tag array to 
   the config.  tags in this list will not be replaced with whitespace. 
   see conf for details. 
 - removed the path_info trailing slash fix 
   the fix will force luci to see documents without an extension as a directory 
 - added 'allowed tags' in PageParser - ex: pre is now allowed
   useful for directory listings
 - add option in config to allow carriage return in the HTML or not 
   this can probably happen anywhere except within <a></a> tags.  if we put a 
   carriage return before </a>, then we get trailing whitespace in our links
   done. see source_delimit option in config (ie. \n follows most closing tags)
   note: if this option is used, we loop through the html content to add line
         breaks, else, we simply use a 'join ""'.     
 - problems with value="" attribute of option, radio tag
   pushing empty attributes can mess up input tags
   ex: if a tag (like option/radio) has the value attribute specified 
   as "" (empty), then the value attribute should be added to the tag (hence 
   the reason for 'if exists'). If the value attribute is not specified in the 
   tag, then it should not be included as the value outside the tag should be 
   the result

Thursday, September 9th 2004 at 4:40 p.m. - luci/0.93b

 - cleanup warnings (ie. -w) 
   added proper testing for $domain_str in UtilFunctions
   when luci.conf was updated, the reference to cryptkey was not. fixed 
   init the tags stack and the html array ref in PageParser
   test for defined on content-length header for frameset pages
 - cleanup conf
 - remove commented (unused) code

Wednesday, September 8th 2004 at 11:10 a.m. - luci/0.92b

 - repeating site navigation: && 
   JW: "It would be nice if site navigation items (as opposed to page 
    navigation items), could be at the end of the page instead of at the top."  
   SM: "I think css will solve this problem.  The only other way around this 
    (easily) would be to add special 'comment' tags that luci could parse for 
    and would force luci to skip or print some specified HTML."
    we will add this feature in a future release if requested.
 - array ref the frame and frameset html strings for consistency
 - added hidden fields to replicate a submit via image
   for pages that are dependent on image submit, we cannot replicate the
   .x .y coordinate values passed, but if only using image submit for
   looks and possibly capturing the fact that the button was pressed it should 
 - anchors are being picked up as hrefs.  should probably test for 
   href-less anchors
   fixed.  anchors will not be delimited, and work properly 
 - look at style a:hover, a:active { color: ; }
   fixed.  incorrect specification in template
 - rename parser.cgi -> luci.cgi
   done.  also renamed the conf luci.conf
 - external links - from && 
   [note: some content snipped]
   JW: "[This raises] the bigger question:  why do we boot the user out of luci 
    when they visit an external link we're sending them to.  I assume there is 
    some technical-ish reason but it seems a bit mean and annoying from the 
    sight-challenged user's point of view?"
   SM: "If a user leaves one of the domains specified in the config (ex:,,, etc...), then a link is considered to be 
    external.  This will require us to add domains that do not fall under our 
    unb structure such as, although adding domains is not an 
    issue - easily done in the config.  The reason for having this feature is 
    that without restriction on the URL, a user can fetch any URL he/she 
        Our initial concern was that a user may attempt to download large 
    content from an external server.  If a user were to invoke the application 
    several times in parallel against a very large document, this could possibly 
    impact server and network performance.  As stated, this was an initial 
    concern.  Kyle and I have added a feature that allows the application owner 
    to specify a maximum download size in the config.  Our development 
    version is currently set at 1MB.  If a user tries something larger than the
    max, they will get an error page explaining the error, and asking them to 
    contact us [application owner] for further discussion.  
        Another concern: Should we be allowing our network bandwidth for 
    surfing external websites?  Essentially, this is what luci would allow 
    without the restriction.  
        Third: luci is not guaranteed to work 100% correctly with really 
    'AWFUL' html.  We are lucky that most users at UNB (at least those 
    with more popular sites) tend to use a good editor such as Dreamweaver to 
    build their pages.  That being said, if a page at UNB has a problem when 
    being parsed by luci, we can easily fix the HTML.  I am not sure how we 
    support the application wrt external sites.  Perhaps a good disclaimer 
    would be all that is required.
        Allowing luci to parse anything is as simple as (not) setting a 
    specific parameter in the config."
   If the 'allowed_domain' parameter is left empty in the config, then any 
   requested URL will be parsed.  As stated here, there are some issues to be
   taken under consideration if you decide to allow any URL.  
 - shouldn't external links open in a new browser window? 
   external_target in the config specifies external link behavior 
 - config tds and allow only spaces or line breaks  (see
   decided against this.  if needed, this could be added in a future release.  
   Spaces look ok.  
 - separate adjacent links with more than white space 
   there is now an option in the config to allow either white space or [] 
   (block) as the delimiter. area hrefs are also delimited (map).

Friday, September 3rd 2004 at 4:45 p.m. - luci/0.91b

 - The following change requiremens from should help luci 
   maintain a sites Bobby(tm) compliance
 - allow 'id' attribute in the following tags: 
        a, form, input, select, area    
        option, textarea, frameset, frame
        map - it's automatic (we don't manipulate the map tag)
 - put <label> tags back in the html
 - replace <b> tags with <strong>
 - add lang="en" to <html> tag
 - add DOCTYPE before html 
 - <style> tag needs type attribute: <style type="text/css">
 - place language meta tag after <HEAD>
 - id style (#id) should be unique, yet class tags can be used more than once:
   change #small style to .small and replace id="small" with class="small"
 - footer table found in content.tmpl:
        add summary attribute to <table>
        add <thead>, <th>, <tbody>, <tfoot>
        remove <caption>: according to Bobby(tm) 
        (see: it is 
        recommended that you use <caption> 
         where a table is used to provide data.  The table we've provided 
         was used specifically for layout.
 - try converting content string (self->{html}) to an array 
   done. all html content is now stored in an array ref: self->{html}
 - with these additions, Luci should at a minimum maintain a sites Bobby(tm) 
   status.  It shouldn't degrade Bobby(tm) approval.

Thursday, August 19 2004 at 10:41 a.m. - luci/0.90b

 - html has been templated using HTML::Template 
 - if an image link contains no alternative text, it will be labelled 
   'undescribed'.  perhaps we need to allow the option to set it to the 
   associative URL in config 
     we've added the ability to set the 'undescribed' text in the config file.  
     allowing href here looks somewhat cumbersome, but should be looked at in 
     a future release
 - frame page refresh
   when adjusting display settings from a frames page, all frames will be 
   updated upon returning to the referer.  this feature could be added to each 
   option in the 'Page Style Settings' page, but unless requested, we've chosen 
   not to in light of less reloading on the server.  
 - added support for \%rest in cookie manager. 
   see: Http::Cookies ->
 - redirect correct url in browser window
   when a user is redirected, luci will now correct the URL in the location bar.
   allows bookmarking   
 - what about checkboxes/radios/select boxes that are supposed to be checked?
   added selected to attr list for select boxes
   added checked to attr list for checkboxes and radios (input boxes)
 - Line spacing has been added as a user configurable option
 - Taint checking should be turned on.  (and should work fine)
   it is, and works great
 - luci should not parse herself
   if luci were able to parse herself, a substantial load could possibly be 
   applied against a server via recursive parsing.  
   on recurse attempt, the system->default_url is parsed instead.  see config. 
 - ssl
   luci was written to allow access to ssl enabled web sites. although she can 
   handle the protocol on her own, running luci from non-ssl (http) implies 
   un-encrypted communication between luci and the browser.  for complete 
   security, luci should reside behind ssl.  one advantage is those sites which 
   require login via ssl.  your information will pass encrypted.
 - what about error codes from the server
   errors returned by the server are displayed as any other html parsed by 
   luci. it is up to the server admin to provide detailed information in 
   their 404, etc... pages
 - visited links
   this feature works; current colors are not far off of a:link yet can 
   be redefined in config
 - output autoflush: $|++ (see 'man perlvar' $OUTPUT_AUTOFLUSH)
   we've tested this feature to see if our application would take advantage of 
   flushing, but according to the docs, it's only autoflush on output, and we 
   are dumping everything with one statement. (non-incremental)  
   no advantage, and therefore was not used.
 - cookies: size and excessive use
   the cookie specification as per RFC2109 (see: 
   states that a user agent must at LEAST accommodate for a cookie of 4 kb 
   in size.  (quashing the myth that browsers only support cookies 4kb in size)
   luci not only stores all cookies that the user comes across in 
   one single cookie, but also stores any information pertaining to the 
   creation of those cookies within that cookie.
         /HTTP/ for details on cookie creation) 
   as a result, the application should work very well where cookie sizes are 
   moderate.  it is up to the browser how it will perform once the cookie size 
   surpasses the required 4 kb limit.  (truncation a definite possibility)  
   Therefore, application performance wrt cookie size and excessive use 
   is uncertain 
 - put application name in config (ie. user agent) 
 - added error message for max download size exceeded 
 - specify max download size in configuration file 
 - clean up multiple brs 
 - cleanup input URL - add regex against internal domains
 - input type=img
   replaced with submit button
 - tds 
   converted to spaces
 - anchors
   added name attribute to links
 - html content size (user agent has a default?) 
   added the size restriction - see config
 - switch settings to css...look at line spacing
 - what are we going to do with title?
   Title = .... seems good
 - ~s cause problems 
   redirection urls were not resolving wrt the current target. fixed
 - view image alt tags as an option
 - label links as external 
 - file downloads 
   specify in config what files are to be parsed.  All others are for download 
 - select statement problems
   fixed (removed option tag from stack)
 - directory listing
   works fine
 - htpasswd
   you cannot be logged into more than one htaccess site at a time.  once 
   logged into one site, if the user requests a different 401, they will be 
   prompted for the 401 credentials, and this new data will overwrite that 
   which was set for the initial htaccess site..
 - cookies
   what about expiring cookies according to thier own specs? - at a max of 
   what our cookie expires?
   cookies will expire because they are treated normally when thrown at the 
   server from LWP.  we may hold onto the cookie data for a period of time 
   greater than that required of the cookie, but a cookie should fail if past 
 - what about a time out feature? 
   see LWP::USerAgent docs and constructor in PageFetcher
   timeout can now be specified in the config - default is 180s


See Luci Documentation for more information.