Mailing List Archive

#1856: LostHeader setting req.url to an empty string
------------------------+-----------------------
Reporter: gdelacroix | Owner:
Type: defect | Status: needinfo
Priority: normal | Milestone:
Component: varnishd | Version: trunk
Severity: normal | Resolution:
Keywords: |
------------------------+-----------------------

Comment (by gdelacroix):

Yes, as I said: ''The issue occurs because the regsub actually removes the
url when it's just "/".''

Seems the behavior when removing emptying req.url has changed, but I don't
know which is expected.

And anyway, the wiki page example should be updated because, even if it
doesn't cause trouble before 4.1, it tries to remove the url when it's
"/".

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1856#comment:8>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs

#1856: LostHeader setting req.url to an empty string
------------------------+-----------------------
Reporter: gdelacroix | Owner:
Type: defect | Status: needinfo
Priority: normal | Milestone:
Component: varnishd | Version: trunk
Severity: normal | Resolution:
Keywords: |
------------------------+-----------------------

Comment (by fgsch):

In previous version the request will not fail but further **set req.**
would be ignored.
Starting with 4.1 we fail the request altogether.

I think the issue here is whether we should allow to set variables to an
empty value via vrt_do_string().
These variables are special and it doesn't make sense to set e.g. proto to
"".

In any case, the workspace exhaustion is incorrect here.

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1856#comment:9>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs

#1856: LostHeader setting req.url to an empty string
------------------------+-----------------------
Reporter: gdelacroix | Owner:
Type: defect | Status: needinfo
Priority: normal | Milestone:
Component: varnishd | Version: trunk
Severity: normal | Resolution:
Keywords: |
------------------------+-----------------------

Comment (by lkarsten):

Discussed at (live) bugwash today.

There are two issues: if you mangle req, proto or method in VCL for a non-
hit you end up in a bad place.

The ws overflow handling is wrong, but generalised it is a "vcl author did
something stupid" kind of situation. Add a vcl_500 sub where a one-off 500
error can be configured, instead of the static one we serve now. We
discussed this on the Rotterdam VDD, and the controversy was that the
canned response should be per-request configurable. One solution to this
is to allow the 500 response to be a 302, where the admin can redirect to
a more descriptive page.

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1856#comment:10>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs

#1856: LostHeader setting req.url to an empty string
------------------------+-----------------------
Reporter: gdelacroix | Owner:
Type: defect | Status: needinfo
Priority: normal | Milestone:
Component: varnishd | Version: trunk
Severity: normal | Resolution:
Keywords: |
------------------------+-----------------------

Comment (by fgsch):

Please note that for the ws exhaustion this is not limited to req, proto
and method.

Any variable using vrt_do_string() will suffer from this issue.

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1856#comment:11>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs