[JHV] application does not work behind a proxy

That´s indeed something that should be changed, and it´s not very difficult to do. Anyway, as far as I know, the kdu_server doesn´t allow normal unchunked responses. The only related available parameter I´ve found is one that allows to specify the maximum length of a chunk. If the proxy doesn´t support chunks, by the time being, there is not any available solution yet.

I think Squid 2.6 already partially supported chunked messages. The problem is that it converted chunked messages into unchunked messages, so in this case JHelioviewer would fail (and it shouldn´t do it). According to something I read, the last version 3.1 of Squid fully supports chunked messages. In this case our application should work without problems.

I don't think there is no available solution. Indeed, kdu_show does work with a 1.0 proxy, using "http" mode.
Things are explained here : (but I don't understand everything myself)

http://www.kakadusoftware.com/jpip-kakadu-superceded.pdf
See 11.1.3 on page 27

See also:
http://tech.groups.yahoo.com/group/kakadu_jpeg2000/message/3947

It will be a long time (years, maybe decades) before institutions switch to recent proxies such as Squid 3.1, so I don't think this could be considered as a solution.

Yes, there is a solution that is, as you say, to use the "http" mode, in order to be able to use HTTP/1.0 connections. The problem is that a standard HTTP/1.0 communication involves to establish a new connection for each GET message request/response. As it can be observed, this is maybe good enough for a Web browsing session, but really annoying for a streaming session (specially with high delay links), like the one related to a JPIP session. In order to avoid this limitation, many 1.0 proxies support a kind of persistent connections (not very standard and depend on specific implementations). But, as it can be read in the page you mention:

"... the Kakadu server and client assume that any HTTP proxy with version less than 1.1
will not support persistent connections."

Therefore maybe it´s not worth it to spend time in the issue of implementing the "http" mode in JHelioviewer. The performance achieved by the system in this mode would be really poor. Anyway, since it´s very easy, I would include the support of simple unchunked transfers to the application, just to avoid possible incompatibilities (for example, in the case of Squid 2.6).

You´re right, institutions are not used to use recent developments, like Squid 3.1, instead of well-known and stable, although older ones. But, if an institution really wants to use efficiently JHelioviewer has two available options: to upgrade its proxy or just simply to avoid it. If none of these options are possible, Helioviewer is a perfect alternative.

Thank you for your explanations, it definitely makes sense. If/when you include the support of simple unchunked transfers to support squid 2.6, please mention it in this ticket, I'm interested in testing it.