Nginx, SOAP and POST redirect

[Francis Daly]

On Mon, Oct 05, 2015 at 01:21:47AM -0400, router_master wrote:

Hi there,

I'm a bit unclear on what precisely you are asking.

I make some suggestions below; perhaps you could reply with the details
of what your clients do, and what your upstream server does. That may
help make clear where the actual breakage is, and perhaps what can be
done about it.

(Fundamentally, if you have a client/server interaction and the client
is broken, there's not much you should do except fix the client. If that
isn't an option, then you can investigate what you could change on the
server, or on the intermediate device (nginx, here) to work around the
known brokennesses of the client.)

> I use nginx as frontend for some soap service. This service actually works
> with CWMP protocol, what is based on soap. I mean, that I have session, that
> consists of sequence of HTTP POST requests and responses, where body
> contains SOAP.

So: client sends HTTP POST to nginx. nginx sends HTTP POST to
upstream. upstream sends response to nginx. nginx sends response to
client.

Some part of this does not do what you want.

> It's important, that I can use only POST requests to communicate with
> client.

Just for clarity here: I think you mean that the client will only send
POST to nginx; it will never send GET.

Or do you mean that the client will send GET, but you do not want it to?

Or do you mean that nginx actually sends a HTTP POST request to the client?

> And there is a problem, that some clients has broken browsers (most
> of the clients, actually) and it's not way to fix them quickly. And I want
> to use redirects in this soap session (I mean 307 redirects) But,
> unfortunately, some clients don't support redirects, because they are
> broken.

If they are broken, how are they broken?

What response do you send to them where they do not continue in the way
that you want? What response do you send to them where they do continue
in the way that you want?

Are different clients broken in different ways?


Does your HTTP 307 response come from upstream; or is it created by nginx?

> For example, there is a question about doing redirect in nginx the way I
> want:
> http://serverfault.com/questions/423265/how-to-follow-http-redirects-inside-nginx
> I tried it, but it turns my POST request into GET request and I loose the
> body.

What config did you try?

I haven't tested, but it looks like proxy_method and proxy_set_body
might combine to do part of what you want.

> By the way, redirect may be not what I need. Exactly I need following:
> 
>     1. Client sends to me first message in the session.

So, client sends HTTP POST with some interesting body content.

(How big is the body content? Always small enough that it never needs
to be saved in a file by nginx?)

This is sent to nginx.

Does nginx sent it to upstream?

Should nginx send it to upstream?

>     2. I answer with 401 (because I need authentication)

Is "I" nginx or upstream, here?

Either way, you send a normal HTTP 401 response, and discard the HTTP
body content that you just received.

>     3. Client sends to me the same message, but with authentication header

client sends HTTP POST again, including an extra HTTP header; nginx
sends this to upstream; upstream validates the header (or does nginx?);
and then...

upstream discards the HTTP body content again? Or does something special
with it?

>     4. I need to get the same first message third time, but on the another
> URL.

Why?

It sounds like HTTP 307 is what you want here; but I don't understand what
your application is actually doing, well enough to suggest an alternative.

What does the other URL do that the first one does not? Can the
application be changed so that the other URL is proxy_pass'ed by the
first one after successful authentication?

Can the first request just go to the final URL, and get a 401 from there?

> So, I don't know what to do. Maybe there are any hope that nginx can help me
> or I should rely on another ways to do it? Or I should forget about doing
> redirects?

If you can describe the application requirements, it may be possible to
find a design that fits them.

(It may not all be relevant for this list, of course.)

Generally, intercepting a HTTP redirect is bad because the client does
not see that the redirect happened, and will interpret (for example) html
links in the response relative to what it believes the request url was.

But if your application can reliably work around or avoid that kind
of problem, perhaps you can configure your nginx to break the normal
http rules.

	f
-- 
Francis Daly        francis at daoine.org