Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Boring report coming up.
At work we have this beast called cruise control which
does continuous builds. On failure, it mails to the offenders
and I wanted to have those links available on the internet
and not only on the local intranet.
One way could be to reconfig the cruise control beast
to use auth and https and then just forward that in our firewall.
Since I'm not clever enough to reconfigure the cruisecontroll
junk to do that - it has sort of disgusting tomcat containers
and several hundred XML config files, I thought I should
just let yaws revproxy to it using https + auth. That way I'd get
https + auth and wouldn't have to touch the cruise control config.
And here comes the boring part, the yaws reverse proxy uses two
processes, one which reads from the client and sends to the server
and another which does the opposite. The reason for that is that
passive mode on the sockets is a requirement so that the HTTP chunks
can be read on at a time.
Anyway, the OTP ssl library can't handle the case with one passive
reader and and another writer in another process. If PidA is
reading and PidB writes, then PidB hangs until PidA is done
while its reading. Boring ehhh....
Thus the only solution is to just use one process and active once
sockets, that however means that all of revproxy needs to be rewritten
and it'll also become much slower since he chunking will have to be
done manually. Booooooring.
Otherwise being able to use the yaws reverse proxy to secure
an internal webserver for external usage would be very nice.
So, for your info, revproxy https-->http (and http-->https for that
matter) doesn't work and will not work until either the OTP sll
library is fixed to handle writers in other procsses or the yaws
revproxy is entirely rewritten.
Any takers ??
Claes Wikstrom wrote:
> Boring report coming up.
> So, for your info, revproxy https-->http (and http-->https for that
> matter) doesn't work and will not work until either the OTP sll
> library is fixed to handle writers in other procsses or the yaws
> revproxy is entirely rewritten.
Perhaps the new SSL application in R12B make this easier?