Cannot get location header or follow location

[Osipov, Michael (GS IT PD LD PLM)]

Hi folks,

Im trying to use a REST service which returns with HTTP/1.1 201 along
with the Location of the new resource after a POST request.
Unfortunately, I cannnot write out (-w, redirect_url) the value, so does

$ curl --verbose -X POST --upload-file file.zip https://.../rest/documents --negotiate -u : -H "Content-Type: application/zip"
* Trying ......
* TCP_NODELAY set
* Connected to ... (...) port 8448 (#0)
* ALPN, offering http/1.1
...
* SSL certificate verify ok.

POST .../rest/documents HTTP/1.1
Host: ...
User-Agent: curl/7.60.0
Accept: */*
Content-Type: application/zip
Content-Length: 918
Expect: 100-continue

...
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 201
< Date: Wed, 25 Jul 2018 13:00:25 GMT
< X-Frame-Options: SAMEORIGIN
< Location: https://.../rest/documents/6667f88a-5783-11e8-857e-001f29e7988e
< Content-Length: 0
<
* Closing connection 0

The reason is
https://github.com/curl/curl/blob/5ae22272d1506e5c0e431f4ad60f1dc446f76715/lib/http.c#L3821-L3825.

Curl always assumes the Location header is for redirects (3xx) only and
not for 2xx operations.

Is there a reason to still have this resriction these days? Do you need
another switch to explicit opt out from this?

curl 7.60.0 (i386-portbld-freebsd10.4) libcurl/7.60.0 OpenSSL/1.0.2o zlib/1.2.11
Release-Date: 2018-05-16
Protocols: file http https imap imaps pop3 pop3s rtsp smtp smtps
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets HTTPS-proxy

Michael
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html

[Daniel Stenberg]

Im trying to use a REST service which returns with HTTP/1.1 201 along with
the Location of the new resource after a POST request. Unfortunately, I
cannnot write out (-w, redirect_url) the value, so does not work --location

...

Curl always assumes the Location header is for redirects (3xx) only and not
for 2xx operations.
Is there a reason to still have this resriction these days? Do you need
another switch to explicit opt out from this?

The write out variable is also called "redirect_url" because it relates wo the
URL "it would have redirected to" - so it is definately and clearly made for
the redirect case and redirects are always 30X responses.

Expanding it to also work for non-3xx cases where the Location: header is used
is an intersting suggestion. It should probably need to use another name or
something to differentiate from the existing implied meaning that it was a 3xx
response.

I can't say that it will land in my top prio list of things to work on, but I
wouldn't object to a patch that made this funtionality come real.

[Osipov, Michael]

Post by Daniel Stenberg

Post by Osipov, Michael (GS IT PD LD PLM)
Im trying to use a REST service which returns with HTTP/1.1 201 along
with the Location of the new resource after a POST request.
Unfortunately, I cannnot write out (-w, redirect_url) the value, so

...

Post by Osipov, Michael (GS IT PD LD PLM)
Curl always assumes the Location header is for redirects (3xx) only
and not for 2xx operations.
Is there a reason to still have this resriction these days? Do you
need another switch to explicit opt out from this?

The write out variable is also called "redirect_url" because it relates
wo the URL "it would have redirected to" - so it is definately and
clearly made for the redirect case and redirects are always 30X responses.
Expanding it to also work for non-3xx cases where the Location: header
is used is an intersting suggestion. It should probably need to use
another name or something to differentiate from the existing implied
meaning that it was a 3xx response.
I can't say that it will land in my top prio list of things to work on,
but I wouldn't object to a patch that made this funtionality come real.

That's sounds really fair. I'd look into it next month. Shouldn't be too
hard to implement.

Michael
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiq