your mail

[Francis Daly]

On Thu, May 02, 2013 at 01:57:47PM -0700, Paul N. Pace wrote:
> On Thu, May 2, 2013 at 1:21 PM, Francis Daly <francis at daoine.org> wrote:
> > On Thu, May 02, 2013 at 01:05:29PM -0700, Paul N. Pace wrote:

Hi there,

> >> Other than that, I tried to follow both guides to the letter. When I
> >> go to http://lists.example.com I get redirected to
> >> http://lists.example.com/mailman/listinfo (on Chrome and FF, but not
> >> IE) and I get a 400 Bad Request Request Header Or Cookie Too Large.
> >
> > Different redirection per client is unexpected. I'm guessing that the
> > browser cache wasn't cleared? It's frequently simplest to test using
> > "curl" to see exactly what response is sent.
> 
> I did try clearing cache and cookies as well as opening the site on a
> device that had never opened it (my BlackBerry) and received the same
> error.

Chrome, FF, and Blackberry get a redirect, and IE gets some other
unspecified response? nginx access log and error log should indicate
why that difference is there.

> Curl just states "moved permanently" as per the changes put in the
> sites-available file (see below).

"curl -i" will show the actual http response including headers; that
is probably most useful. (And then make a new request to the redirect
location with whatever cookie headers are indicated, and repeat until
you see the failure.)

> >> Any ideas on where to start looking?
> >
> > Your nginx.conf almost certainly does a "proxy_pass" to the web server
> > that actually runs mailman.
> >
> > I suggest you confirm that mailman is installed and working correctly
> > on that web server -- if it isn't, nginx won't help.
> 
> How to do this other than viewing the mailman page?

View the mailman page directly, without going through nginx.

Either go to 127.0.0.1, or get the other web server to listen on an
accessible ip:port and use that.

> > If the 400 error comes from nginx, there should be something in the logs
> > to indicate the nature of the problem.
> 
> Strangely, the logs do not state any errors.

That suggests that you may not be talking to this nginx.

Be aware, though, that a 400 error (Bad Request) may be logged to the
file appropriate at http{} level, not at server{} level, since a bad
request may not allow the correct server to be determined.

> This is the server block
> I added to sites-available file (mostly) as per the nginx wiki. Was I
> supposed to add this to the nginx.conf file?

The wiki page I see doesn't mention sites-available.

When nginx starts it reads one file, usually nginx.conf.

That file may use the "include" directive to cause other files to be
read as if they appeared directly in the one file.

If you don't know whether this server{} block is being used for this
request, you could try adding something like

  location = /test/ { return 200 "this is it"; }

and then do "curl -i http://lists.example.com/test/" and see what
comes back.

>         location = / {
>                 rewrite ^ /mailman/listinfo permanent;
>         }

So: when you access http://lists.example.com/, you expect a redirect
to http://lists.example.com/mailman/listinfo.

>         location /mailman/ {
>                 include proxy_params;
>                 proxy_pass http://127.0.0.1/;
>                 proxy_set_header Host $host;
>                 proxy_set_header X-Real-IP $remote_addr;
>         }

And when you access http://lists.example.com/mailman/listinfo, you expect
whatever the other web server returns.

But the other web server is the one listening on 127.0.0.1:80. Does
"netstat -an | grep LISTEN | grep 80" show that that is there and
working? I thought your nginx was bound to port 80?

	f
-- 
Francis Daly        francis at daoine.org