Hello!
I found an issue in the standard ngx_http_sub_filter_module shipped
with the Nginx core while playing with it tonight.
The minimal use case to reproduce this issue is as follows:
location = /t {
default_type text/html;
return 200 ababac;
sub_filter abac X;
}
The output of location = /t is "ababac" instead of "abX".
ngx_http_sub_filter_module just fails to find a match when it really
should.
It seems that the parser in this module is just too simple and its
state machine does not take into account the potential ambiguity
involved in the user patterns.
If this limitation is by design, then IMHO it should be mentioned in
the official documentation:
http://nginx.org/en/docs/http/ngx_http_sub_module.html
Best regards,
-agentzh
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
I found an issue in the standard ngx_http_sub_filter_module shipped
with the Nginx core while playing with it tonight.
The minimal use case to reproduce this issue is as follows:
location = /t {
default_type text/html;
return 200 ababac;
sub_filter abac X;
}
The output of location = /t is "ababac" instead of "abX".
ngx_http_sub_filter_module just fails to find a match when it really
should.
It seems that the parser in this module is just too simple and its
state machine does not take into account the potential ambiguity
involved in the user patterns.
If this limitation is by design, then IMHO it should be mentioned in
the official documentation:
http://nginx.org/en/docs/http/ngx_http_sub_module.html
Best regards,
-agentzh
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel