Version 2.8: What's New
 

I am pleased to announce the release of Version 2.8.

What's New in Version 2.8.0

• New Seat Map Options
  • Apollo and Galileo seat maps can now be requested in just a click, and without a need to go through a 'dummy booking' process! Both text-based (recommended for advanced users), and graphical seat map versions are now available.
  
  
• New Flight/Operational Info Manager
  • Provides quick and easy access to operational flight info, historical performance data, and flight tracking.
  
  
• Automatic Update Notification
  • Once every 10 days, the Tool will automatically check to see if there is a newer version available for download, and, if so, an appropriate message will be displayed. This process takes only a second or two to complete, and should not cause any noticeable delays.

[Download Version 2.8.0 Now].

Sabre searches seem erratic - e.g. C availability on NZ on certain flights / days cycles between 0 and 3 and back again (and again) on successive searches only a few seconds apart. The 3 was correct, at least by availability checking on AirNZ website itself.

Wow! Lots of pretty nifty enhancements. ^ Thanks, KVS.

Thanks for the report. This appears to be similar to the issue in post #1231 above -- could be a problem with a link between Sabre and NZ's back-end systems ...

SeatMaps not working
 

Installed new version; Now, whenever clicking on:
ANY of the Apollo:ITN Graphical seat map links
ANY of the Apollo:ITN Text seat map links

receive an INSTANT error (I mean this error comes up faster than you can blink): Unable to initialize the Seat Map engine. Please try a different Seat Map Method. "ERROR: The requested URL could not be retrieved."

That appears to be a connection/network issue on your end -- are you using a proxy server and/or some third-party 'personal firewall'-type software by any chance? Also, have you looked at the troubleshooting section of the KVS Tool FAQ?

Am using Firewall however, have tried with firewall OFF and same behavior. (When the Firewall is enabled, its connection log feature does show a new local port opened at time of the click to look at the seatmap to 151.193.199.65:80 and 62bytes sent 0Bytes received).

Am I using a proxy server? No.

Have looked at the FAQ (and would suggest that it would be much easier for me to lreview the FAQ if it were on your website instead of or in addition to hard-to-read Flyertalk forum).

I don't think there is any more troubleshooting I can do without knowing what kind of URL/call the program is attempting.

UPDATE: I have tried with another [slow/dial-up] ISP and do not have the problem.
The ISP for my high-speed connection at present location does use transparent proxy and This article might give you some clues as to why KVS is not working with it (they use Squid). I, of course, have no control over my ISP's use of Squid, and in the location I am at do not have alternative ISP. I would imagine some KVS users in some locations (esp airports/public access places) may run into similar problems...?

Thanks for the info. While that article did not actually contain any information regarding the particular bug in the Squid transparent proxy server that was causing your error situation, it certainly was correct in stating that "transparent proxying (more commonly known as TCP hijacking) [..] is to be avoided at all costs".

The good news is that there is a work-around and I have just uploaded an updated version. Pls download the latest version (setup screen should say 2.8.0.R1), and let me know...

The quote "Transparent proxying (more commonly known as TCP hijacking) is like Network Address Translation (NAT) in some respects: It is to be avoided at all costs, and only used if there absolutely, positively, no other way." is old and probably the most inaccurate statement I've ever seen on an O'Reilly site.

Transparent proxying is not referred to as TCP hijacking. (The term is used to describe Man-in-the-middle attacks which may or may not have anything to do with any form of web usage.) NAT isn't to be avoided at all costs. (Almost every home network does it, for a start.) Transparent proxying is used regularly by ISPs (esp. those with expensive overseas peering costs) with almost no downside and the suggestion that it should be avoided because some applications are badly written and don't conform to standards is ignorant tripe.

No, but that's, essentially, how it works.

Indeed, NAT has very little to do with transparent HTTP proxying, nor is capable of causing such problems.

It saves $$$ for the ISPs, but there are no real 'upsides' in it for the user. The downsides are numerous, including the possibility of out-of-date content being served, and, as the above case demonstrates, the possibility of a buggy proxy server software frustrating a user with unnecessary and avoidable errors.

In a competitive market, saving money for the ISP is an upside for the user in itself, as the ISP will be able to charge less and/or not go broke. The other upside is speed. For me, my ISP is about 40 ms away and US sites are 300 ms away. I run a local proxy on my home network, partly because my ISP doesn't run a proxy in this state. (They do for users in their home state.)

There is absolutely nothing preventing an ISP from offering a conventional proxy server for those users who want it, instead of "hijacking" everyone's traffic behind their backs.

True. However, most users wouldn't even know how to set a proxy in their browser anyhow, so the advantages, both in speed and cost, are largely lost when an ISP does this.

Emotive terms such as "hijacking" and "behind their backs" don't seem relevant to the discussion. They are doing something which assists their whole user base because the majority are too dumb to do it themselves. Having used ISPs with transparent proxying for years, I believe there is only one important potential downside: The transparent proxy devices must have redundancy and 100% uptime.

Yes, R1 works - thanks for the quick fix.

[I am no fan at all of this ISP or Squid as a transparent proxy --- there is 1 website I can't use at all=connection refused= and this 3rd-world ISP/tech support which barely understands English is unable to correct the problem; they have the word 'bittorrent' blocked in the proxy so that an URL that has that character sequence results in 'Access Denied'; there TWO instances of the proxy, and different releases at that - 1 in the building I'm in, and another further along as evidenced by the headers sent to web servers:
and, when the proxy gets out of whack (which happens all too frequently), any request for anything on port 80 times out, but other services (https://, pop, etc.) work just fine.....]

Glad to hear that!