For some reason my customers GSA always returns 10 results no matter what we send with the "num" parameter:
http://www.google.com/support/enterprise/static/gsa/docs/admin/72/gsa_doc_set/xml_reference/request_format.html#1076882
Is there a global configuration that we are missing that overrides what is sent as a parameter?
In GSA, there isn't a globally configuration which can override the num-parameter. If you use the num-parameter in the search query, it should return that number of results you assign in the parameter (with a maximum of 1000). So, you are sure that there are more than 10 results for the query you used?
The other thing I can think of, is that a proxy handles the search requests and responses. The parameters can then be controlled by this proxy, so whatever parameter you add in the URL is ignored since the proxy / the backend handles these.
Related
I have a question about the light-rest-4j URL validation, for example, if I have a POST request path /party, if I type the path as /party11, I will get error: No handler defined for path /party11, but if I put /party?qqqq, It will pass through, and system treat it as /party should we add validation for this? Our QA team creates this as a defect, in case user input it by mistake, they expect to have error message return.
The light-rest-4j framework validates the request/response based on the OpenAPI specification during the runtime; however, it only validates based on the spec — nothing more and nothing less. In most cases, the spec will define the type of headers, query parameters, path parameters, and cookies, as well as if they are required. We make sure these are validated as defined. For anything that is not defined in the spec, we are doing nothing. For example, an extra query parameter or an extra header in the request will be ignored as they are not defined in the spec. We cannot do any negative validation as we don't know if any client will add additional headers or query parameters for tracing, auditing, etc. A request that comes from one client might be different than another one comes from the same client through a gateway or proxy.
I am working on a Jmeter LDAP test plan and the test plan has to populate an attribute on the LDAP that is multi-valued.
When I do an LDAP search sampler, I noted that the value I get back is a string, with the values separated by ", ".
But, if I take the same comma-separated string and try to do an LDAP modify or add, using either an LDAP Request or LDAP Extended Request, I get an error.
So I am wondering if there is a way that the Jmeter LDAP Request or LDAP Extended Request can do that?
Thanks,
Jim
EDIT: When I try to use an Extended LDAP Request modification test/add with the attribute of "", I get this error in the Jmeter GUI response:
When attempting to modify entry cn=xxx... to replace the set of values for attribute lastlogindate, value "20181023085627-04, 20181024063205-04" was found to be invalid according to the associated syntax: The provided value "20181023085627-04, 20181024063205-04" is not a valid generalized time value because it contains an invalid character '-' at position 14
The strange part is that even though I have Jmeter to log at debug level, I don't see any detail on the error in the Jmeter.log, but/so I am guessing that that error message is coming from the Jmeter client itself. I noticed that the message says:
to replace the set of values
so it seems like it recognizes that I am trying to modify/replace a multi-value, but it doesn't seem to like the syntax of the replacement values string(s).
Does anyone know what the correct format SHOULD be?
I found the answer to my own question, or at least "A" answer: It appears that I can use an Extended LDAP request, and add the same attribute in that request, multiple times. So for example, if I am populating an attribute named "foo" the Extended LDAP request would have the following:
attribute value opcode
foo 12345 add
foo 12346 add
etc.
I think I also need to do a replace with no value, to empty the attribute, before all the adds.
Foe search interactions, while there is support for specifying the number of items expected in the response using the _count parameter, we are not able to find any reference to a parameter to specify the page number.
The _query parameter can be used for custom queries, but is that an option or is there a better alternative.
For example, what is the standard way to request for the second page of a patient resultset with each page having 10 records? -
GET Patient?_count=10&[pagenumber?]=2
There's no mechanism to navigate to a specific page. You use the URLs provided in Bundle.link (e.g. previous, next, first, last) to navigate through the search result set.
When doing a search operation in elasticsearch i want the metadata to be filtered out and return only "_source" in the response. I'm able to achieve the same through "search" in the following way:
out1 = es.search(index='index.com', filter_path=['hits.hits._id',
'hits.hits._source'])
But when i do the same with scan method it just returns an empty list:
out2 = helpers.scan(es, query, index='index.com',
doc_type='2016-07-27',filter_path= ['hits.hits._source'])
The problem may be with the way i'm processing the response of 'scan' method or with the way i'm passing the value to filter_path. To check the output i parse out2 to a list.
The scan helper currently doesn't allow passing extra parameters to the scroll API so your filter_path doesn't apply to it. It does, however, get applied to the initial search API call which is used to initiate the scan/scroll cycle. This means that the scroll_id is stripped from the response causing the entire operation to fail.
In your case even passing the filter_path parameter to the scroll API calls would cause the helper to fail because it would strip the scroll_id which is needed for this operation to work and also because the helper relies on the structure of the response.
My recommendation would be to use source filtering if you need to limit the size of the response or use smaller size parameter than the default 1000.
Hope this helps,
Honza
You could pass filter_path=['_scroll_id', '_shards', 'hits.hits._source'] to the scan helper to get it to work. Obviously that leaves some metadata in the response but it removes as much as possible while allowing the scroll to work. _shards is required because it is used internally by the scan helper.
Why are there GET and POST requests in AJAX as it does not affect page URL anyway? What difference does it make by passing sensitive data over GET in AJAX as the data is not getting reflected to page URL?
You should use the proper HTTP verb according to what you require from your web service.
When dealing with a Collection URI like: http://example.com/resources/
GET: List the members of the collection, complete with their member URIs for further navigation. For example, list all the cars for sale.
PUT: Meaning defined as "replace the entire collection with another collection".
POST: Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is usually included as part of the data returned by this operation.
DELETE: Meaning defined as "delete the entire collection".
When dealing with a Member URI like: http://example.com/resources/7HOU57Y
GET: Retrieve a representation of the addressed member of the collection expressed in an appropriate MIME type.
PUT: Update the addressed member of the collection or create it with the specified ID.
POST: Treats the addressed member as a collection in its own right and creates a new subordinate of it.
DELETE: Delete the addressed member of the collection.
Source: Wikipedia
Well, as for GET, you still have the url length limitation. Other than that, it is quite conceivable that the server treats POST and GET requests differently; thus the need to be able to specify what request you're doing.
Another difference between GET and POST is the way caching is handled in browsers. POST response is never cached. GET may or may not be cached based on the caching rules specified in your response headers.
Two primary reasons for having them:
GET requests have some pretty restrictive limitations on size; POST are typically capable of containing much more information.
The backend may be expecting GET or POST, depending on how it's designed. We need the flexibility of doing a GET if the backend expects one, or a POST if that's what it's expecting.
It's simply down to respecting the rules of the http protocol.
Get - calls must be idempotent. This means that if you call it multiple times you will get the same result. It is not intended to change the underlying data. You might use this for a search box etc.
Post - calls are NOT idempotent. It is allowed to make a change to the underlying data, so might be used in a create method. If you call it multiple times you will create multiple entries.
You normally send parameters to the AJAX script, it returns data based on these parameters. It works just like a form that has method="get" or method="post". When using the GET method, the parameters are passed in the query string. When using POST method, the parameters are sent in the post body.
Generally, if your parameters have very few characters and do not contain sensitive information then you send them via GET method. Sensitive data (e.g. password) or long text (e.g. an 8000 character long bio of a person) are better sent via POST method.
Thanks..
I mainly use the GET method with Ajax and I haven't got any problems until now except the following:
Internet Explorer (unlike Firefox and Google Chrome) cache GET calling if using the same GET values.
So, using some interval with Ajax GET can show the same results unless you change URL with irrelevant random number usage for each Ajax GET.
Others have covered the main points (context/idempotency, and size), but i'll add another: encryption. If you are using SSL and want to encrypt your input args, you need to use POST.
When we use the GET method in Ajax, only the content of the value of the field is sent, not the format in which the content is. For example, content in the text area is just added in the URL in case of the GET method (without a new line character). That is not the case in the POST method.