从相对 URL(给定基本 URL)确定完整 URL 的最快方法是什么

发布于 2024-07-04 13:03:33 字数 94 浏览 9 评论 0原文

我目前正在使用模块 URI::URL 从相对 URL 生成完整 URL; 但是,它的运行速度没有我希望的那么快。 有谁知道另一种可能更快的方法?

I'm currently using the module URI::URL to generate a full URL from a relative URL; however, it isn't running as fast as I'd like it to be. Does anyone know another way to do this that may be faster?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

嘿咻 2024-07-11 13:03:33

也许我搞错了,但行不通

$full_url = $base_url . $relative_url

? IIRC Perl 文本处理速度非常快。

@lennysan 啊,当然可以。 抱歉我无能为力,我的 Perl 已经很生疏了。

Perhaps I got the wrong end of the stick but wouldn't,

$full_url = $base_url . $relative_url

work? IIRC Perl text processing is pretty quick.

@lennysan Ah sure yes of course. Sorry I can't help, my Perl is pretty rusty.

孤独患者 2024-07-11 13:03:33

可能取决于你如何获得这两个字符串。 也许安全、防火的方法就是 URI::URL 或类似库中的方法,其中将考虑所有替代方案,包括恶意方案。 也许会慢一些,但在某些环境下,子弹飞到你自己脚上的速度会更快。

但是,如果您期望有一些简单且不棘手的内容,可以查看它是否以 /、../ 链或任何其他字符开头。 第一个将放置服务器名称 + url,第二个从基本 uri 开始的切路径,直到进入其他 2 个替代方案之一,或者只是将其添加到基本 url。

Could depend a bit how you obtain those 2 strings. Probably the secure, fireproof way to do that is what is in URI::URL or similar libraries, where all alternatives, including malicious ones, would be considered. Maybe slower, but in some environments faster will be the speed of a bullet going to your own foot.

But if you expect there something plain and not tricky could see if it starts with /, chains of ../, or any other char. The 1st would put the server name + the url, the 2nd chop paths from the base uri till getting in one of the other 2 alternatives, or just add it to the base url.

旧夏天 2024-07-11 13:03:33

布伦丹,我应该澄清一下,我不能保证相对路径会是什么样子。 它可能非常棘手(例如前面有斜杠、没有斜杠、有“../”等)。

彼得,这就是我现在正在使用的。 或者比使用 URI::URL->new($path)->abs 更快?

Brendan, I should have clarified that I can't guarantee what the relative path is going to look like. It could be pretty tricky (e.g. has a slash at the front, doesn't have a slash, has "../", etc).

Peter, that's what I'm using now. Or is that faster then using the URI::URL->new($path)->abs?

风铃鹿 2024-07-11 13:03:33

下面的代码应该可以工作。

$uri = URI->new_abs( $str, $base_uri )

您还应该查看search.cpan.org 上的 URI 页面

The following code should work.

$uri = URI->new_abs( $str, $base_uri )

You should also take a look at the URI page on search.cpan.org.

猛虎独行 2024-07-11 13:03:33

刚刚发生在这篇文章中解决 Redhat/Centos/Fedora Perl 实现中对 URI 产生深远影响的缺陷。

如果您正在运行这些 Linux 版本之一,您可能需要从原始源代码(而不是 RPM 源代码)重新编译 Perl。

我意识到任何在 Redhat 5.2、Centos 5.2 或 Fedora 9 上使用发行版 Perl 解释器运行 Perl 代码的人都可能是受害者。 是的,即使您的代码不使用花哨的祝福/重载习惯用法,许多 CPAN 模块也会使用! 谷歌搜索显示有 1500 多个模块使用 bless/overload 习惯用法,其中包括一些非常流行的模块,例如 URI、JSON。 ...

... 此时,我决定从源代码重新编译 perl。 错误消失了。 差异是惊人的。 一切都变得非常快。 CPU 在平均负载低于 0.10 时冷却,我们处理数据的速度提高了 100 倍到 1000 倍!

Just happened across this article which point out shortcomings in Redhat/Centos/Fedora implementations of Perl which affect URI profoundly.

If you are running one of these Linux flavours, you might want to recompile Perl from original source (not RPM source).

I realized that anyone running perl code with the distribution perl interpretter on Redhat 5.2, Centos 5.2 or Fedora 9 is likely a victim. Yes, even if your code doesn’t use the fancy bless/overload idiom, many CPAN modules do! This google search shows 1500+ modules use the bless/overload idiom and they include some really popular ones like URI, JSON. ...

... At this point, I decided to recompile perl from source. The bug was gone. And the difference was appalling. Everything got seriously fast. CPUs were chilling at a loadavg below 0.10 and we were processing data 100x to 1000x faster!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文