On Wed, Oct 31, 2012 at 07:02:55AM -0400, gerard breiner wrote:

Hi there,

> curl -k -i https://127.0.0.1 as
> curl -k -i https://sogo.mydomain.fr give:
> ------------------------------
> HTTP/1.1 302 Found
> Server: nginx/0.7.67
> Date: Wed, 31 Oct 2012 10:37:27 GMT
> Content-Type: text/plain; charset=utf-8
> Connection: keep-alive
> content-length: 0
> location: /SOGo/
> --------------------------------

So it redirects to /SOGo/. What happens when you do that manually?

curl -k -i https://127.0.0.1/SOGo/

Probably it will redirect again, or else return some html. What you
probably want to do is to manually step through the full login sequence
until you see the specific problem. Then you can concentrate on that
one request.

(Also: that doesn't look like nginx 1.2.4. Are you sure that your test
system is exactly what you expect it to be?)

> From sogo.log
> Oct 31 11:44:05 sogod [29392]: SOGoRootPage successful login for user
> 'gbreiner' - expire = -1 grace = -1

This is from a later time. So some other requests were involved here.

> [31/Oct/2012:11:44:05 GMT] "POST /SOGoSOGoSOGo/connect HTTP/1.0" 200 27/62
> 0.016 - - 4K
>
> I think the "POST /SOGoSOGoSOGo/" is wrong ...

Can you see where that request came from? Probably it was the "action"
of a html form within the response of a previous request. Maybe that
will help show why SOGo is repeated here.

(That said, the HTTP 200 response suggests that the web server was happy
with the request.)

> (it is not the navigator because under apache2 it works very fine).

Searching the web for "sogo and nginx" returns articles from people who
claim to have it working.

I suggest you step back and do exactly one thing at a time. With your
original "location ^~ /SOGo" block, did it all work apart from the
initial redirect? If not, fix that first.

The SOGo installation guide mentions an apache config file, and says
"The default configuration will use mod_proxy and mod_headers to relay
requests to the sogod parent process. This is suitable for small to
medium deployments.".

That suggests that your proxy_pass, proxy_redirect, and proxy_set_header
directives may be enough.

Good luck with it,

f
--
Francis Daly francis@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx