History log of /unit/src/nxt_http_return.c (Results 1 – 8 of 8)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 2147:7bf58b1b18c4 13-Jul-2022 Zhidao HONG

Var: dynamic variables support.

This commit adds the variables $arg_NAME, $header_NAME, and $cookie_NAME.


Revision tags: 1.27.0-1, 1.27.0
# 2102:9ad9385c16e1 16-May-2022 Alejandro Colomar

Wrapped debug code in '#if (NXT_DEBUG)'.


# 2101:39785641d1a2 17-May-2022 Alejandro Colomar

Fixed memcpy(dest, NULL, 0) Undefined Behavior.

nxt_str_null() setted the loc.start pointer to NULL, which was
being passed to memcpy(3) through nxt_debug(). That caused
Undefined Behavior, so we n

Fixed memcpy(dest, NULL, 0) Undefined Behavior.

nxt_str_null() setted the loc.start pointer to NULL, which was
being passed to memcpy(3) through nxt_debug(). That caused
Undefined Behavior, so we now pass an empty string.

show more ...


# 2098:9a890f0c56aa 09-Apr-2022 Alejandro Colomar

Supporting empty Location URIs.

An empty string in Location was being handled specially by not sending a
Location header. This may occur after variable resolution, so we need to
consider this scena

Supporting empty Location URIs.

An empty string in Location was being handled specially by not sending a
Location header. This may occur after variable resolution, so we need to
consider this scenario.

The obsolete RFC 2616 defined the Location header as consisting of an absolute
URI <https://www.rfc-editor.org/rfc/rfc2616#section-14.30>, which cannot be an
empty string. However, the current RFC 7231 allows the Location to be a
relative URI <https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2>, and a
relative URI may be an empty string <https://stackoverflow.com/a/43338457>.

Due to these considerations, this patch allows sending an empty Location header
without handling this case specially. This behavior will probably be more
straightforward to users, too. It also simplifies the code, which is now more
readable, fast, and conformant to the current RFC. We're skipping an
allocation at request time in a common case such as "action": {"return": 404}

show more ...


# 2081:c68e6afffb84 05-Apr-2022 Alejandro Colomar

Supporting variables in "location".

............
Description:
............

Before this commit, the encoded URI could be calculated at
configuration time. Now, since variables can only be resolved

Supporting variables in "location".

............
Description:
............

Before this commit, the encoded URI could be calculated at
configuration time. Now, since variables can only be resolved at
request time, we have different situations:

- "location" contains no variables:

In this case, we still encode the URI in the conf structure, at
configuration time, and then we just copy the resulting string
to the ctx structure at request time.

- "location" contains variables:

In this case, we compile the var string at configure time, then
when we resolve it at request time, and then we encode the
string.

In both cases, as was being done before, if the string is empty,
either before or after resolving variables, we skip the encoding.

...........
Usefulness:
...........

An example of why this feature may be useful is redirecting HTTP
to HTTPS with something like:

"action": {
"return": 301,
"location": "https://${host}${uri}"
}

.....
Bugs:
.....

This feature conflicts with the relevant RFCs in the following:

'$' is used for Unit variables, but '$' is a reserved character in
a URI, to be used as a sub-delimiter. However, it's almost never
used as that, and in fact, other parts of Unit already conflict
with '$' being a reserved character for use as a sub-delimiter, so
this is at least consistent in that sense. VBart suggested an
easy workaround if we ever need it: adding a variable '$sign'
which resolves to a literal '$'.

......
Notes:
......

An empty string is handled as if "location" wasn't specified at
all, so no Location header is sent.

This is incorrect, and the code is slightly misleading.

The Location header consists of a URI-reference[1], which might be
a relative one, which itself might consist of an empty string[2].

[1]: <https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2>
[2]: <https://stackoverflow.com/a/43338457>

Now that we have variables, it's more likely that an empty
Location header will be requested, and we should handle it
correctly.

I think in a future commit we should modify the code to allow
differentiating between an unset "location" and an empty one,
which should be treated as any other "location" string.

.................
Testing (manual):
.................

{
"listeners": {
"*:80": {
"pass": "routes/str"
},
"*:81": {
"pass": "routes/empty"
},
"*:82": {
"pass": "routes/var"
},
"*:83": {
"pass": "routes/enc-str"
},
"*:84": {
"pass": "routes/enc-var"
}
},
"routes": {
"str": [
{
"action": {
"return": 301,
"location": "foo"
}
}
],
"empty": [
{
"action": {
"return": 301,
"location": ""
}
}
],
"var": [
{
"action": {
"return": 301,
"location": "$host"
}
}
],
"enc-str": [
{
"action": {
"return": 301,
"location": "f%23o#o"
}
}
],
"enc-var": [
{
"action": {
"return": 301,
"location": "f%23o${host}#o"
}
}
]
}
}

$ curl --dump-header - localhost:80
HTTP/1.1 301 Moved Permanently
Location: foo
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:06 GMT
Content-Length: 0

$ curl --dump-header - localhost:81
HTTP/1.1 301 Moved Permanently
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:08 GMT
Content-Length: 0

$ curl --dump-header - localhost:82
HTTP/1.1 301 Moved Permanently
Location: localhost
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:15 GMT
Content-Length: 0

$ curl --dump-header - -H "Host: bar" localhost:82
HTTP/1.1 301 Moved Permanently
Location: bar
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:23 GMT
Content-Length: 0

$ curl --dump-header - -H "Host: " localhost:82
HTTP/1.1 301 Moved Permanently
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:29 GMT
Content-Length: 0

$ curl --dump-header - localhost:83
HTTP/1.1 301 Moved Permanently
Location: f%23o#o
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:22:23 GMT
Content-Length: 0

$ curl --dump-header - -H "Host: " localhost:84
HTTP/1.1 301 Moved Permanently
Location: f%23o#o
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:22:44 GMT
Content-Length: 0

$ curl --dump-header - -H "Host: alx" localhost:84
HTTP/1.1 301 Moved Permanently
Location: f%23oalx#o
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:22:52 GMT
Content-Length: 0

$ curl --dump-header - -H "Host: a#l%23x" localhost:84
HTTP/1.1 301 Moved Permanently
Location: f%2523oa#l%2523x%23o
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:23:09 GMT
Content-Length: 0

$ curl --dump-header - -H "Host: b##ar" localhost:82
HTTP/1.1 301 Moved Permanently
Location: b#%23ar
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:25:01 GMT
Content-Length: 0

show more ...


Revision tags: 1.26.1-1, 1.26.1, 1.26.0-1, 1.26.0, 1.25.0-1, 1.25.0
# 1903:f17827e75e25 24-May-2021 Zhidao HONG

Router: split nxt_http_return_conf_t from nxt_http_action_t.

No functional changes.


Revision tags: 1.24.0-1, 1.24.0, 1.23.0-1, 1.23.0, 1.22.0-1, 1.22.0, 1.21.0-1, 1.21.0, 1.20.0-1, 1.20.0, 1.19.0-1, 1.19.0, 1.18.0-1, 1.18.0, 1.17.0-1, 1.17.0
# 1432:f650ced3012a 20-Mar-2020 Valentin Bartenev

Implemented "location" option for "return" action.

This allows to specify redirects:

{
"action": {
"return": 301,
"location": "https://www.example.com/"
}
}


# 1429:9a0d78f144ac 27-Mar-2020 Valentin Bartenev

Implemented "return" action.

The "return" action can be used to immediately generate a simple HTTP response
with an arbitrary status:

{
"action": {
"return": 404
}
}

This

Implemented "return" action.

The "return" action can be used to immediately generate a simple HTTP response
with an arbitrary status:

{
"action": {
"return": 404
}
}

This is especially useful for denying access to specific resources.

show more ...