1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
|
Title: Dillo is changing URL and appending a 0.
Author: rouilj
Created: Mon, 24 Jun 2024 06:17:33 +0000
State: closed
When I try to go to https://rouilj.dynamic -dns.net/demo/. It looks like the server responds with a
200 code and 14k of data. However I never see the data. Instead dillo displays a 403 error by
accessing: https://rouilj.dynamic -dns.net/demo/0. (Just remove the space before the dash to get the
actual url. Just trying to cut down on traffic to the url.)
The site does return a cookie using SameSite that dillo complains about, but it seems to save the
cookie.
Dillo logging does show both urls in a Nav_open_url log line.
Other URL's on the site work. Other browsers (firefox, chrome, links, w3m) on the original URL operate
correctly as well.
Any ideas on how I can figure out why dillo is "rewriting" and "redirecting" to an invalid URL?
I looked at the docs, the dillo help text and the dillorc. There doesn't seem to be a more verbose
mode I can set. dillorc is the default with no changes. cookiesrc is default accept (but it failed the same way with default deny). ~/.dillo has no other config files.
Thanks.
--%--
From: rodarima
Date: Mon, 24 Jun 2024 10:19:47 +0000
Thanks for the report, it seems to be caused by the meta tag without the redirect URL. Here is a reproducer:
```html
<!DOCTYPE html>
<html>
<head>
<title>Test empty URL refresh</title>
<meta http-equiv="Refresh" content="0">
</head>
<body>
<p>Refresh</p>
</body>
</html>
```
```
% dillo /tmp/meta-redirect.html
dillo_dns_init: Here we go! (threaded)
TLS library: OpenSSL 3.3.0 9 Apr 2024
Enabling cookies as from cookiesrc...
Nav_open_url: new url='file:/tmp/meta-redirect.html'
...
Nav_open_url: new url='file:/tmp/0'
```
I'll see if I can fix the parser.
--%--
From: rouilj
Date: Mon, 24 Jun 2024 14:20:56 +0000
Hello:
In message ***@***.***>,
rodarima writes:
>Thanks for the report, it seems to be caused by the meta tag without
>the redirect URL. Here is a reproducer:
>
>```html
><!DOCTYPE html>
><html>
> <head>
> <title>Test empty URL refresh</title>
> <meta http-equiv="Refresh" content="0">
> </head>
> <body>
> <p>Refresh</p>
> </body>
></html>
>```
Ah, that makes sense. I was wondering where 0 was comming from. Dillo
is interpreting the refresh delay time as the url value.
>```
>% dillo /tmp/meta-redirect.html
>dillo_dns_init: Here we go! (threaded)
>TLS library: OpenSSL 3.3.0 9 Apr 2024
>Enabling cookies as from cookiesrc...
>Nav_open_url: new url='file:/tmp/meta-redirect.html'
>...
>Nav_open_url: new url='file:/tmp/0'
>```
Yup that's what I saw.
>I'll see if I can fix the parser.
Sounds good. The refresh is part of the technique for detecting if
javascript is available/enabled. See:
https://wiki.roundup-tracker.org/IsJavascriptAvailable
for details.
This allows the server to replace javascript driven interactions with
native element. For example replace an multiple value autocomplete
widget with a select multiple element.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
--%--
From: rodarima
Date: Mon, 24 Jun 2024 17:45:26 +0000
Hi,
>Sounds good. The refresh is part of the technique for detecting if
>javascript is available/enabled. See:
>
> https://wiki.roundup-tracker.org/IsJavascriptAvailable
>
>for details.
>
>This allows the server to replace javascript driven interactions with
>native element. For example replace an multiple value autocomplete
>widget with a select multiple element.
This would not work in Dillo, even with my proposed patch. It will just
ignore the meta refresh tag.
You could redirect the page to another URL like this:
<noscript>
<meta http-equiv="Refresh" content="0;URL=https://your.site/demo/?nojs=1">
</noscript>
And then set the cookie when the nojs parameter is set.
Also you can probably load the non-JS version by default, and then
enhance the site replacing the elements you want (or the whole page)
when JS is enabled.
Another question is if Dillo should support redirects to the same page
or not, as these could cause loops.
--%--
From: rouilj
Date: Mon, 24 Jun 2024 21:55:40 +0000
Hello:
In message ***@***.***>,
rodarima writes:
>>Sounds good. The refresh is part of the technique for detecting if
>>javascript is available/enabled. See:
>>
>> https://wiki.roundup-tracker.org/IsJavascriptAvailable
>>
>>for details.
>>
>>This allows the server to replace javascript driven interactions with
>>native element. [...]
>
>This would not work in Dillo, even with my proposed patch. It will just
>ignore the meta refresh tag.
So dillo will just ignore the tag if it doesn't explicitly specify the
url?
>You could redirect the page to another URL like this:
>
><noscript>
><meta http-equiv="Refresh" content="0;URL=https://your.site/demo/?nojs=1">
></noscript>
>
>And then set the cookie when the nojs parameter is set.
I did try something similar originally. However modifying the URL
isn't a great UI.
The url that is presented may or may not have query parameters and a
fragment. I have to create the new URL (with @no_js=1) on the server
and preserve the original query args. But IIRC a bigger issue was that
the server doesn't see the fragment. The redirect ended up removing
the fragment from the URL.
Using a refresh content="0" kept the fragment because the browser was
just reusing the current page url and it had access to the fragment.
I didn't find anything documented that specified that was required,
but it worked for the browsers and OS's I tested on.
Also the URL, unlike cookies, can be saved. I prefer to not put
settings like that in the URL where it could end up in a bookmark.
>Also you can probably load the non-JS version by default, and then
>enhance the site replacing the elements you want (or the whole page)
>when JS is enabled.
The default supplied web interface works on text based browsers by not
requiring JS. It is very much a web 1.0 application.
However people can redefine the web interface and choose JS first with
a non-js fallback if they wish. IIRC that's the scenario that
IsJavascriptAvailable was trying to solve.
>Another question is if Dillo should support redirects to the same page
>or not, as these could cause loops.
I would think it should. Other browsers detect redirect loops. I don't
know the mechanism, but think they use some mechanism of checking the
number of times the same url has been redirected to in a row (possibly
within some short period of time). I assume dillo has some method of
detecting redirect loops via 3XX redirects. Maybe that could be used
here pretending a "0" second meta redirect is like a 307 redirect
status?
Redirecting to the same page with a longer period of time is also
useful. For example the user can set the page I referenced to refresh
after 60 seconds. This makes sure that the list of issues is kept up
to date.
Sorry I don't have any other ideas on how other browsers handle this
valid HTML meta tag.
Have a great week.
--
-- rouilj
--%--
From: rodarima
Date: Tue, 25 Jun 2024 19:23:46 +0000
Hi,
>So dillo will just ignore the tag if it doesn't explicitly specify the
>url?
Dillo will only try to follow the redirect if the following properties
are all met:
- It has delay zero
- The destination is not to the same URL
- The current URL doesn't have the URL_SpamSafe flag.
- The new URL is considered safe (doesn't start with "dpi:")
The URL_SpamSafe is set in some cases like for local files and other
less common cases, but is not very well documented.
When the delay is greater than zero, it will show a message in the top
of the page to let the user follow the redirect manually.
>>Another question is if Dillo should support redirects to the same page
>>or not, as these could cause loops.
>
>I would think it should. Other browsers detect redirect loops. I don't
>know the mechanism, but think they use some mechanism of checking the
>number of times the same url has been redirected to in a row (possibly
>within some short period of time). I assume dillo has some method of
>detecting redirect loops via 3XX redirects. Maybe that could be used
>here pretending a "0" second meta redirect is like a 307 redirect
>status?
>
>Redirecting to the same page with a longer period of time is also
>useful. For example the user can set the page I referenced to refresh
>after 60 seconds. This makes sure that the list of issues is kept up
>to date.
>
>Sorry I don't have any other ideas on how other browsers handle this
>valid HTML meta tag.
I opened issue #206 to implement support for redirects controlled by a
configuration option, so we let the users choose what they want. I will
leave this issue to focus on the bug that it was redirecting to /0
because it was parsing the delay as the new url.
I also think it has some good use cases, but not sure if it should be
enabled by default. For example, some pages create a long list of
redirects to try to trick the user into being unable to go back
(easily). On the other hand, having a monitoring page that refreshes
every minute is a good use case.
|
