I want to input the following command in QuickExec(e.g., using logic operator 'and'）
=404 and ?/path/
Namely, the sessions which response
status equal to 404 and the keyword '/path/' appears in URL will be selected in Fiddler.
Does anyone know how to implement/support these operators in Fiddler?
Nope, logical operators aren't supported today. It's a fun idea though and the base case (=404 /partialpath) is something I'll probably build in soon.
Related
For consistency we need to use the REST URL style syntax (rather than JSON style syntax) when calling our Loopback apis. However, we are having difficulty structuring complex 'where' filters that include both 'and' and 'or' operators. There does not appear to be a way to group mixed conditional logic. For example, how would we create the equivalent of this SQL statement using REST syntax:
SELECT * FROM Customer WHERE (type='retail' OR type='nonprofit') AND terms='monthly'
For example, this does not work:
/api/customer?filter[where][or][0][type]=retail&filter[where][or][1][type]=nonprofit&filter[where][and][2][terms]=monthly
Try with something like this:
/api/customer?filter={
"where": {
"or": [
{"type":"retail"},
{"type":"nonprofit"},
"and": [{"terms":"monthly}]
]
}
}
Take a look to Where filter in "More complex example"
I am trying to work out a similar issue. Looks like you are pretty close, but I believe and is actually the top level comparison, and you are writing your query as if or is. So maybe..
/api/customer?filter[where][and][0][or][0][type]=retail&filter[where][and][0][or][1][type]=nonprofit&filter[where][and][1][terms]=monthly
I have no way to confirm this though as I do not have a functioning local environment with which to test it. Let us know if it works out. Thanks!
Update: Looks like this question has already been answered. https://github.com/strongloop/loopback/issues/3017 BLUF, it isn't possible in Loopback. Use the stringified JSON option.
Try searching for any classes here, e.g. use the string ReportJobMailNotification*
https://jaspersoft.jfrog.io/jaspersoft/webapp/#/search/archive/
It returns no results. Sometimes (seemingly in a random way) it comes up with a warning "Method Not Allowed".
But if you do the same search via REST API you get consistently many results:
https://jaspersoft.jfrog.io/jaspersoft/api/search/archive?name=ReportJobMailNotification*
Any specific reasons why this might happen?
It seems to work now. I guess it was a temporary glitch...
In G-WAN the default URL is in the form mydomain.com/?hello.c
I want to get rid of the ? to have URLs that look like mydomain.com/hello
The user manual mentions substituting a different character such as ' for ?. In that case the URL would look like mydomain.com/'hello.c
But I don't want to use a different character, I want to get rid of the special character completely. Is that possible?
The default language for G-WAN is C. So mydomain.com/?hello means mydomain.com/?hello.c
How do I change the default to a different language, say Java, so that mydomain.com/?hello now means mydomain.com/?hello.java
Can I set different default languages for different virtual hosts?
Finally, how do I change the URL format for passing parameters? According to the user manual the default format is:
mydomain.com/?hello.c&name=Eva
I want to change it to:
mydomain.com/hello?name=Eva
Is that possible?
This has already been asked many times, and a few solutions are found here:
G-WAN handler rewriting solution
You should note, however, that the way you mean to pass arguments as ?something=answer instead of & only applies to the first argument passed. You can't do ?this=that?somethingelse=this because only the first can be ? and the rest must be &. In fact you can ignore using ? completely and only use & with virtually unlimited arguments so it's in fact better to stick to only using &.
It's important to note for future reference to anyone asking similar questions, G-WAN gives you the entire headers through multiple steps of the HTTP transaction and being that you can modify them with c/c++, you can change anything at all that you want before the requests are handled by the server or sent back to the client. The only limitation is your knowledge and imagination.
I have seen the locale added to an URI as a path variable:
/en-US/blah/
or
/blah/en-US
and I have seen it as a request parameter:
/blah?lang=en-US
Is there a standard way that I should be doing it? If not what are the pros and cons of each approach?
I kind of like the request parameter approach because it doesn't require you to pass the locale with every URI (unless you use the second approach and add the locale to the end of the path). Any additional thoughts?
I believe the "standard way" is to use an HTTP "accept language" header. Other than that, if you think it ought to be a parameter (because it's a system-system call or you might request a language other than the browser locale) then it's just a parameter the same as anything else and you should handle it in a similar fashion.
Fun fact: even with this notation "/blah/en-US" it could still be a request parameter. Magic of mod_rewrite and friends.
If you need it as request parameter or part of the url depends of what you want to achieve. If you want to serve static content, you should have it be part of the path. If you want to act dynamically on the chosen locale, you should use it as request parameter, since you don't want to have your scripts replicated several times over different paths just to add different locales.
How can I validate a URL in perl. I mean, the query string has a specific order and all params have specific values (int or string or operator (%2B(+) ect..)).
example : www.mypage/question?name=john&age=21&operation=%2B
Can I control the order (name->age->operation) and the specific values of them?
Thanks
Yes and no.
No, you can't control the order of the parameters as they're submitted to you. Browsers may submit them in a different order, or the user may not be using a browser to submit the query to you.
Yes, you can control the order of the parameters you submit. But, don't rely on this.
You can use Data::Validate::URI to validate a URL.
You shouldn't use a complicated RegEx for controlling parameter values. Either the parameter matches or it doesn't. Either the parameter value is one of the expected options, or it isn't. If it matches, do something. If it doesn't match anything, don't do anything. (Or do a 404, but that can be leveraged against you.) Using anything more complex than "this parameter value should be all numbers" is asking for trouble.