-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[2.1][DomCrawler] Fix relative path handling in links #7244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
$output = array(); | ||
|
||
foreach (explode('/', $path) as $idx => $segment) { | ||
if ('..' === $segment) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
&& $output
to avoid a warning on invalid paths ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But why should it trigger a warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't we have an invalid path that would trigger more pop than the array contains ?
In this case array_pop would generate a warning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wouldn't. AFAIK, it generates a warning only for non-arrays, but in that case there would be a warning on the last line of getUri().
I'll fix it and add another test. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, I should have checked the doc first !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would your code resolve an invalid path (too many "..") in the same manner of a real browser ? (I actually don't know what a browser would do)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vicb It does. A browser will simply ignore the extra ..
when it reaches the root (at least FF does)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just added the test for that case :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perfect then ! thanks @lazyhammer @stof
@fabpot seems like 2.1 as a deps issue if you look at travis logs |
Added relative path canonicalization according to RFC 3986, section 5.2.4
This PR was merged into the 2.1 branch. Commits ------- a4ec677 [DomCrawler] Fix relative path handling in links Discussion ---------- [2.1][DomCrawler] Fix relative path handling in links | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #7219 | License | MIT | Doc PR | n/a Added relative path canonicalization according to RFC 3986, section 5.2.4 --------------------------------------------------------------------------- by vicb at 2013-03-02T14:48:46Z @fabpot seems like 2.1 as a deps issue if you look at travis logs
Added relative path canonicalization according to RFC 3986, section 5.2.4