You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 29, 2024. It is now read-only.
Currently we have this in internal/proxy/proxy.go:
// WebTextHandler fixes links in page and "src" issues in javascript files.// This solution, however, may prevent content streaming. Fix it?funcWebTextHandler() goproxy.RespHandler {
returngoproxy_html.HandleString(
func(sstring, ctx*goproxy.ProxyCtx) string {
c:=RVPNURLMatcher.ReplaceAllString(s, "$1://")
rawURLWithPort:=ctx.UserData.(reqData).rawURLWithPortrawURLWithoutPort:=ctx.UserData.(reqData).rawURLWithoutPortc=strings.ReplaceAll(c, rawURLWithPort[:strings.LastIndex(rawURLWithPort, "/")+1], "") // possible out of bounds?c=strings.ReplaceAll(c, rawURLWithoutPort[:strings.LastIndex(rawURLWithoutPort, "/")+1], "")
returnc
})
}
As the comments indicates, there are several problems.
Issue of "src" in javascript files is not completely resolved. Corruption of scripts still exists on some sites.
Out of bounds in trying to get the string before (including) last "/".
Streaming of response. Apparently for now the result is first "ReadAll"-ed, processed and sent to the browser.
Solutions and plans:
1: This requires a close inspecting and some experiments on some sites.
2: A better way to do the extracting. Note since this is also related to "src" issue as mentioned above, if we can find other ways to solve that, there is no need to do this substitution anymore.
3: This is more of a performance concern. Let's have a detailed explanation in the next reply.
And one more small thing: CSS files can probably be excluded from being applied with this handler.
The text was updated successfully, but these errors were encountered:
For 3:
Well, I'm not sure if browsers really start rendering one element before its downloading finishes.
The current behavior is that "Waiting (TTFB)" takes a long time, and "Content Download" phase finishes like lightning (as rwppa runs locally).
As introducing streaming text replacement will add overhead and requires more work, it would be better to know if this have a perceivable impact on user experience.
An extra bonus would be being more stable and have a lower memory usage.
So, if having decided to optimize this:
Streaming text replacement: https://github.com/icholy/replace
This one supports regular expressions besides normal bytes replace and string replace.
Character set conversion is a big problem. One solution is to convert content to utf-8, do processing and converts back. Another is to convert the new string (in strings.ReplaceAll) to the given encoding. (However, it looks like that regexp cannot be encoded this way.) Refer to following resources:
Currently we have this in
internal/proxy/proxy.go
:As the comments indicates, there are several problems.
Solutions and plans:
And one more small thing: CSS files can probably be excluded from being applied with this handler.
The text was updated successfully, but these errors were encountered: