Re: ViewVC Exception

[Bob Proulx]

Thomas De Contes wrote:
> Bob Proulx a écrit :
> > Please try the https protocol instead.  Does that work better?
> 
> I suppose the 2nd possibility is the right one, and the problem did
> not recur, so I can't say what it would have been like.

It's not the typical problem being reported.  If https works then keep
using it.

> If you think that we should always avoid http because it can be corrupted, 
> then:
> 
> 1
> I fixed the link given here:
> http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/README?view=markup
> (to https://savannah.nongnu.org/projects/rapid/ )
> Am I right ?

Yes.  I think it is *safer* to always document https now.  However I
am opposed to blocking http.  Let me explain.

There are those who wish to actively block http and only allow https.
But just because something can be broken for some cases does not mean
that it is always broken in all cases.  And it does not mean that we
should actively break those who need http access.

This is just me typing extemporaneously and I might write something
wrong since but...

* If your clock has failed and you boot without a good time source
then it is likely that you will be unable to contact any https sites.
Because the time will be different to the point that the certificate
will not validate.

* Likewise for mandatory DNSSEC.  DNS Security Extensions.  If the
time is too far wrong then it can't validate the DNS entry.

* If you are behind a blocking firewall then https may be impossible
to use.  In which case http may be the only available protocol.  There
are many who must exist behind these firewalls and it would be a
tragedy to block them from access to Free Software out of a misplaced
sense of trying to protect others.  First do no harm.

* Not every peek at documentation or every software download requires
a theoretical level of life or death security!

So I think it is okay and good to document https as the primary
protocol and to encourage it.  But I don't want to block http.
Because if someone needs http then they should be able to recognize
their need and use it as needed.

I don't think we need to go to extremes of documenting every use of
https as also have a potential fallback to http either.  That would be
too much noise and clutter everywhere.  It would be like documenting
the use and purpose of the shell's command line IFS variable *for
every command*.  It is definitely in use every time we type in any
command but if someone attempted to document every possible thing at
every possible place then that documentation quickly becomes
impossible to use in practice.

> 2
> Why does the server redirects to https only when we are logged in?
> And when we clic on "Browse Sources Repository" (and links that
> point out of the sub-domain), it goes on http even from https.

Probably because it wasn't noticed before.  Developers are always
logged in!  For example when I visit I remain in https.

But when I test this now I do see that it defaults to http for the
standard address.  This can be changed in the "Select features" in the
admin page.  But it would be somewhat tedious to update all of the
links manually.

I myself have done very little Savannah web UI development.
Maintenance has fallen to the very few who work on it.  This would be
an excellent area for contributed patches!

> > Also the past day and a half has had some problems with memory
> > exhaustion due to external influence starting a git clone then either
> > dropping the connection or getting dropped due to networking issues.
> 
> > However its Emacs and the repository is large and the resulting git
> > pack-objects process consumes 800 MB of active RAM before deciding to
> > write anything to the closed file descriptor and then exiting.  That's
> > been a problem.
> 
> Yes, it seems to be a problem.
> I was thinking about migrate from subversion to git, but maybe it's
> too soon? What do you think about that?

Such a question!  When I meet parents with several children, I usually
avoid asking them, "Who is your favorite child?" :-)

I don't think it is a matter of "soon" or "too soon".  Git is very
stable and mature.  It is used by thousands.  It's fine.  I use git
myself and I like git.

But I also know that many people do not like git.  They much prefer
svn or hg instead.  And in some workflows there are advantages.  Like
any benchmark everything has a sweet good spot and also a bad worst
case.

It is not a matter of time.  It is a matter of features and work flow
and what you want to use.  The choice is yours.

> > We have mitigation in effect now to detect those as
> > quickly as practical and kill them as they are occurring.
> 
> Thank you for having fix it. :-)

Unfortunately the Internet is a hostile place.  8 billion people in
the world and all "doing stuff".  Some of it on the Internet.  Some
good, some bad, some indifferent.  It is a continuous process of
reacting to abuse.  And the type of abuse is always changing.

> >> And when I reloaded it, I got :
> >> 
> >> An error occurred while reading CGI reply (no response received)
> > 
> > This seems much more likely.  As that is basically a 503 Bad Gateway
> > due to the backend not being able to load in time due to memory
> > stress.  It eventually loads but not before the timeout which is
> > already quite long.
> 
> Ok, I think too.
> As said, the problem did not recur, so I think that this time the problem was 
> on your side.

We do appreciate problem reports such as 503 Bad Gateway errors.
Because we don't want those to happen.  But it is the squeaky wheel
that gets the oil.  We are all volunteers and when there isn't
anything squeaking we tend to be working on out $DAY_JOBS and not
otherwise.  It is okay to make noise when there are problems.  That's
how things get fixed.  It's okay to do this! :-)

> > I worry the web browser is caching some result.  Please the next time
> > you have this problem try using a command line tool such as wget or
> > curl which avoids web browser cache issues.  For example:
> > 
> >    wget -O- -q -S 
> > 'http://svn.savannah.gnu.org/viewvc/rapid/trunk/gtk_peer/?pathrev=3'
> > 
> > Does that work when at the same time the browser does not?
> 
> Thank you, I keep it for the next time. :-)

There I intentionally said http since we were discussing http proxies
and such.  But that command with https should work the same.  If they
ever work different then that is also useful information.

Both are possible to see the same _somewhat_random_ 503 Bad Gateway
errors at the same rate.  They are the same backend processing.  But
if one always works and the other always fails then that is a
transport protocol issue between.

The process of debugging a problem is one of dividing the problem up
into smaller parts and trying to identify each part separately.

Bob

signature.asc
Description: PGP signature