I have the following code in my Django template:
<a href="{% url myapp.views.myview foobar %}">
so, what's the right way to handle the situation where "foobar" contains an asterisk (for example, "*1234")? At the moment, Django is throwing this error:
Caught NoReverseMatch while rendering: Reverse for 'myapp.views.myview.myview'
with arguments '(u'*86743',)' and keyword arguments '{}' not found.
Commonly, You'd see this if you're specifying a url rule with a \w regex. For example:(r'^myview/(?P<myparam>\w.+)/$', 'myview') would cause this. Broadening the regex a bit to allow the ampersand should cure your ills.
Make sure that one of the entries in your urlconf actually matches the arguments you pass. If you only allow digits ([0-9]+) then an asterisk won't match.
Related
When I run this test and it fails:
func TestCaseA(t *testing.T){
t.Run("my name with spaces", func (t *testing.T){
t.Error("some error message")
})
}
then the name of the test is modified (spaces are changed to underscores) in the output:
--- FAIL: TestCaseA (0.00s)
--- FAIL: TestCaseA/my_name_with_spaces (0.00s)
main.go:10: some error message
FAIL
Why does it do this?
Here's a working example: https://play.golang.org/p/viZjC60Dazg
It's explained in this blog post: https://blog.golang.org/subtests
The full name of a subtest or sub-benchmark is a slash-separated list of its name and the names of all of its parents, starting with the top-level. The name is the corresponding function name for top-level tests and benchmarks, and the first argument to Run otherwise. To avoid display and parsing issues, a name is sanitized by replacing spaces with underscores and escaping non-printable characters. The same sanitizing is applied to the regular expressions passed to the -run or -bench flags.
Some examples could be to make it simpler for automated tools to process the test output, to avoid issues with the shell making regex arguments containing spaces appearing as multiple arguments etc. I'd rather avoid using spaces than deal with this magic renaming.
I found the most definitive answer I could, in the code itself, of course. The rewrite function comment reads
rewrite rewrites a subname to having only printable characters and no white space.
https://golang.org/src/testing/match.go#L133
As to why? I'm guessing JimB hit the nail on the head with his comment:
As for why, maybe because it's easier to reference names without spaces in the cli?
White spaces are bad for cli.
I have many files with small differences. The included file contains this, which tries to differentiate on one part of a longer path:
<!--#if expr="${DOCUMENT_URI}=/internet/"-->Internet<!--#else-->Intranet<!--#endif-->
In the error log I get
AH01337: Could not parse expr "${DOCUMENT_URI}=/internet/" in /opt/apache/htdocs/ssi/time.shtml: Parse error near '$'
I find many variations on this theme, like no braces, parentheses around the inside of the quotes, space before the comment end or =~, but nothing helps. There doesn't seem to be a debug setting for mod_include, which would tell me what's wrong...
Another variant I found is
<!--#if expr='"${DOCUMENT_URI}"=~/internet/'-->
this gives no error. But it always chooses the else branch, likewise with REQUEST_URI, as though the variables were unset. But I can echo them fine. I also tried /.+internet.+/ in case it was anchoring this.
Since these are CGI variables I also tried loading cgid_module – no good either.
As of version 2.3.13, mod_include has switched to the new ap_expr syntax for conditional expressions in #if flow control elements.
Add the SSILegacyExprParser on directive to switch to the old syntax which is compatible with Apache HTTPD version 2.2.x and earlier.
http://httpd.apache.org/docs/current/mod/mod_include.html#ssilegacyexprparser
As many other people noted you can use the v("foo") style, but the examples given in the Apache 2.4 documentation (http://httpd.apache.org/docs/2.4/expr.html#examples) give this form:
<!--#if expr="%{DOCUMENT_URI} =~ /internet/"-->Internet<!--#else-->Intranet<!--#endif-->
Note the % instead of $ on the variable, and the =~ for regex match.
I've just tested this and it works fine.
(Or use SSILegacyExprParser on as also mentioned, to allow for backward-compatibility with the 2.2.x format. But I expect this compatibility will be removed at some point in the distant future..)
I got it working with:
<!--#if expr='v("foo") = "bar"' -->
foo is bar
<!--#endif -->
See Flow Control Elements
Newer Apache versions use ap_expr. I just wanted to add the relevant link: Apache docs. Note that the v function is not yet documented.
The variable resolves to a text string, so it needs to be enclosed in double quotes, and you need to escape those double quotes.... (warning this may be deprecated syntax - I used it on my old Apache 1 and just never changed it when upgrading):
<!--# if expr="\"$DOCUMENT_URI\"=/internet/" -->
Hello my rewrite rule is failling sometimes because my urls have % signs in them.
For example this url:
http://www.chillisource.co.uk/product/Grocery/Dr.%20Burnoriums%20Psycho%20Juice/1/B005MSE5KG/Psycho_Juice_70%_Ghost_Pepper
This is my rewrite rule:
RewriteRule ^product/([a-zA-Z]+)/([\sa-zA-Z0-9\-\+\.]+)/([0-9]+)/([A-Z0-9]+)/([a-zA-Z0-9]+) /product?&cat=$1&q=$2&page=$3&prod=$4&prodName=$5
How can I modify the 5th rule ([a-zA-Z0-9]+) to not fail on when there is a % in the product name ?
Thanks in advance.
Perhaps, it's not %20, but space. That is, the URL passed to rewrite adter urldecoding. If not, then just add percent sign to the range. (if yes — space).
---- Forget this part, I misunderstood the question ----
From what I get from the mod_rewrite documentation (http://httpd.apache.org/docs/current/mod/mod_rewrite.html), you should not have to deal with hex encoded characters (I assume that from the following statement:
THE_REQUEST
The full HTTP request line sent by the browser to the server (e.g., "GET /index.html HTTP/1.1"). This does not include any additional headers sent by the browser. This value has not been unescaped (decoded), unlike most other variables below.
In fact, using mod_rewrite would be practically impossible since you'd have to deal with that EVERYWHERE, e.g., you can always write %41 instead of 'A'.
--- But the following still is true ---
But your rewrite rule can't work, at least not with the request URL you posted: The last part of the regex "([a-zA-Z0-9]+)" is FAR too strict. In this case, it fails for the following reasons:
It lacks a treatment of the percent sign, as in "70%"
You forgot to include the underscore "_"
Try adding at least these two characters ("[a-zA-Z0-9%_]+") and it should work.
Is there a way to verify only part of text present?
If there is a text "Warning: A15P09 has not been activated." I need to verify the text is present. However, 'A15P09' is not always the same, so I cannot do something like
Selenium.IsTextPresent("Warning: A15P09 has not been activated.");
I might do something like:
Selenium.IsTextPresent("has not been activated.");
But is there another way to verify this in Selenium. Please let me know if there is.
Thanks!
You could use getText and then do any normal regex that your language supplies for examining that result.
Edit: And for some languages you can do isTextPresent on a pattern modified string. The documentation states:
Various Pattern syntaxes are available
for matching string values:
glob:pattern: Match a string against a
"glob" (aka "wildmat") pattern. "Glob"
is a kind of limited
regular-expression syntax typically
used in command-line shells. In a glob
pattern, "*" represents any sequence
of characters, and "?" represents any
single character. Glob patterns match
against the entire string.
regexp:regexp: Match a string using a
regular-expression. The full power of
JavaScript regular-expressions is
available.
exact:string: Match a
string exactly, verbatim, without any
of that fancy wildcard stuff.
If no
pattern prefix is specified, Selenium
assumes that it's a "glob" pattern.
Are square brackets in URLs allowed?
I noticed that Apache commons HttpClient (3.0.1) throws an IOException, wget and Firefox however accept square brackets.
URL example:
http://example.com/path/to/file[3].html
My HTTP client encounters such URLs but I'm not sure whether to patch the code or to throw an exception (as it actually should be).
RFC 3986 states
A host identified by an Internet
Protocol literal address, version 6
[RFC3513] or later, is distinguished
by enclosing the IP literal within
square brackets ("[" and "]"). This
is the only place where square bracket
characters are allowed in the URI
syntax.
So you should not be seeing such URI's in the wild in theory, as they should arrive encoded.
Square brackets [ and ] in URLs are not often supported.
Replace them by %5B and %5D:
Using a command line, the following example is based on bash and sed:
url='http://example.com?day=[0-3][0-9]'
encoded_url="$( sed 's/\[/%5B/g;s/]/%5D/g' <<< "$url")"
Using Java URLEncoder.encode(String s, String enc)
Using PHP rawurlencode() or urlencode()
<?php
echo '<a href="http://example.com/day/',
rawurlencode('[0-3][0-9]'), '">';
?>
output:
<a href="http://example.com/day/%5B0-3%5D%5B0-9%5D">
or:
<?php
$query_string = 'day=' . urlencode('[0-3][0-9]') .
'&month=' . urlencode('[0-1][0-9]');
echo '<a href="http://example.com?',
htmlentities($query_string), '">';
?>
Using your favorite programming language... Please extend this answer by posting a comment or editing directly this answer to add the function you use from your programming language ;-)
For more details, see the RFC 3986 specifying the URL syntax. The Appendix A is about %-encoding in the query string (brackets as belonging to “gen-delims” to be %-encoded).
I know this question is a bit old, but I just wanted to note that PHP uses brackets to pass arrays in a URL.
http://www.example.com/foo.php?bar[]=1&bar[]=2&bar[]=3
In this case $_GET['bar'] will contain array(1, 2, 3).
Pretty much the only characters not allowed in pathnames are # and ? as they signify the end of the path.
The uri rfc will have the definative answer:
http://www.ietf.org/rfc/rfc1738.txt
Unsafe:
Characters can be unsafe for a number of reasons. The space
character is unsafe because significant spaces may disappear and
insignificant spaces may be introduced when URLs are transcribed or
typeset or subjected to the treatment of word-processing programs.
The characters "<" and ">" are unsafe because they are used as the
delimiters around URLs in free text; the quote mark (""") is used to
delimit URLs in some systems. The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it. The character "%" is unsafe because it is used for
encodings of other characters. Other characters are unsafe because
gateways and other transport agents are known to sometimes modify
such characters. These characters are "{", "}", "|", "\", "^", "~",
"[", "]", and "`".
All unsafe characters must always be encoded within a URL. For
example, the character "#" must be encoded within URLs even in
systems that do not normally deal with fragment or anchor
identifiers, so that if the URL is copied into another system that
does use them, it will not be necessary to change the URL encoding.
The answer is that they should be hex encoded, but knowing postel's law, most things will accept them verbatim.
Any browser or web-enabled software that accepts URLs and is not throwing an exception when special characters are introduced is almost guaranteed to be encoding the special characters behind the scenes. Curly brackets, square brackets, spaces, etc all have special encoded ways of representing them so as not to produce conflicts. As per the previous answers, the safest way to deal with these is to URL-encode them before handing them off to something that will try to resolve the URL.
For using the HttpClient commons class, you want to look into the org.apache.commons.httpclient.util.URIUtil class, specifically the encode() method. Use it to URI-encode the URL before trying to fetch it.
StackOverflow seems to not encode them:
https://stackoverflow.com/search?q=square+brackets+[url]
Best to URL encode those, as they are clearly not supported in all web servers. Sometimes, even when there is a standard, not everyone follows it.
According to the URL specification, the square brackets are not valid URL characters.
Here's the relevant snippets:
The "national" and "punctuation" characters do not appear in any
productions and therefore may not appear in URLs.
national { | } | vline | [ | ] | \ | ^ | ~
punctuation < | >
Square brackets are considered unsafe, but majority of browsers will parse those correctly. Having said that it is better to replace square brackets with some other characters.