Jorge wrote:
On Fri, Apr 02, 2010 at 07:07:50PM +0000, corvid wrote:
I'd only suggest considering whether adding a URL flag (e.g. URL_FilterOut) provides more flexibility/clarity without having to add the 'requester' parameter to the API.
Can you elaborate a bit on how/where the flag would be set, and how it would help?
I haven't looked at it in enough depth to offer a good alternative yet. Just noticed of the API changes, made an extra couple of passes above the code considering the flag or having referer in the DilloUrl struct.
The idea is to commit it and to consider the alternatives later.
All right, then. Committed. Everyone: 1) This will surely require various tweaks. 2) If it threatens to drive you insane in the meantime, there's a dillorc option. Do you think we should put image/stylesheet redirection under its control? [for reference, this thread dates back to http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007118.html ]
On Tue, Apr 06, 2010 at 02:41:50AM +0000, corvid wrote:
Jorge wrote:
On Fri, Apr 02, 2010 at 07:07:50PM +0000, corvid wrote:
I'd only suggest considering whether adding a URL flag (e.g. URL_FilterOut) provides more flexibility/clarity without having to add the 'requester' parameter to the API.
Can you elaborate a bit on how/where the flag would be set, and how it would help?
I haven't looked at it in enough depth to offer a good alternative yet. Just noticed of the API changes, made an extra couple of passes above the code considering the flag or having referer in the DilloUrl struct.
The idea is to commit it and to consider the alternatives later.
All right, then. Committed.
Cool! Quite interesting to look at all those DENY's!
Everyone: 1) This will surely require various tweaks. 2) If it threatens to drive you insane in the meantime, there's a dillorc option.
Do you think we should put image/stylesheet redirection under its control?
I guess, if we would also restrict redirects, we could guarantee, that we only load from a domain the user has entered at the loacation bar or clicked on in a link - which sounds reasonable to me. OTH do we know how that would affect usability with major sites? Cheers, Johannes BTW. I also updated the display branch accordingly.
Johannes wrote:
On Tue, Apr 06, 2010 at 02:41:50AM +0000, corvid wrote:
Do you think we should put image/stylesheet redirection under its control?
I guess, if we would also restrict redirects, we could guarantee, that we only load from a domain the user has entered at the loacation bar or clicked on in a link - which sounds reasonable to me. OTH do we know how that would affect usability with major sites?
In Cache_redirect(), non-root urls never redirect currently.
On Tue, Apr 06, 2010 at 02:41:50AM +0000, corvid wrote:
Jorge wrote:
On Fri, Apr 02, 2010 at 07:07:50PM +0000, corvid wrote:
I'd only suggest considering whether adding a URL flag (e.g. URL_FilterOut) provides more flexibility/clarity without having to add the 'requester' parameter to the API.
Can you elaborate a bit on how/where the flag would be set, and how it would help?
I haven't looked at it in enough depth to offer a good alternative yet. Just noticed of the API changes, made an extra couple of passes above the code considering the flag or having referer in the DilloUrl struct.
The idea is to commit it and to consider the alternatives later.
All right, then. Committed.
Everyone: 1) This will surely require various tweaks. 2) If it threatens to drive you insane in the meantime, there's a dillorc option.
While testing a bit more I found a problem with redirects: http://nibble.develsec.org doesn't seem to load properly when same_domain is enabled. The problem seems to be a_Nav_push(bw, bw->meta_refresh_url,a_History_get_url(NAV_TOP_UIDX(bw))); in Nav_redirection0_callback(). a_History_get_url(NAV_TOP_UIDX(bw)) is not necessarily the proper requester. Things seem to work in this example with a_Nav_push(bw, bw->meta_refresh_url,bw->nav_expect_url); but I guess bw->nav_expect_url is also not always set properly.
participants (2)
-
corvid＠lavabit.com -
Johannes.Hofmann＠gmx.de