My jmeter log indicates me alot of same kind of warnings which makes me clueless
WARN - jmeter.protocol.http.sampler.HTTPSamplerBase: Null URL detected (should not happen)
what should i look for? i ve googled around but cant find any info related to my issue.
Add: The Test at all is running fine.
This happens when you check download resources.
The message is issued when one of the URLs returned by the HTML Page parser is null.
This is not supposed to happen, if it does it seems to be a bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55092
As per your bug report, it happens because you have iframe tags which source is:
about:blank
Bug will be fixed in 2.10 version of JMeter
As a workaround you can uncheck download resources, you test will then work only on dynamic resources, not static ones (images,css,js ...)
Related
I have recorded a simple get/post test using the Blazemeter chrome plugin and am tweaking it in JMeter to be ready to use. However, the test fails because one of the embedded resources fails to load, which if it was correct, would be understandable.
I don't know if I am not understanding what I am seeing in the View Results Tree listener but I have some questions:
I don't need to download embedded resources but even though the box is NOT ticked on the http requests, they are still shown as downloaded. However, for the GET, these are dowloaded successfully.
I think that the post is failing and the same page is being returned by the server but when it comes to reloading the embedded resources, they all succeed except for one to fonts.googleapis.com, even though the same request always works for the get request
The failure is always the same each time I run it. Always, the embedded resources download correctly with GET and always that single 12th request to google fails with a 400.
Please can someone advise how to 1) Actually stop embedded resources from being downloaded and 2) work out how to debug why a second request to the same resource always fails even though it is simply an embedded font?
JMeter Chrome Extension adds HTTP Request Defaults configuration element which populates the values for all the HTTP Request samplers in its scope. So if you don't want to download embedded resources (although it's not recommended) you need to open "Advanced" tab of the Defaults configuration element and untick the box there
There is a special property which controls whether a problem with fetching an embedded resource is treated as failure or not, if you would like to download embedded resources but at the same time to ignore failures you can add the next line to user.properties file:
httpsampler.ignore_failed_embedded_resources=true
upon JMeter restart problems with embedded resources won't fail the parent HTTP Request sampler. See Configuring JMeter user manual chapter for more details if needed.
I'm trying to add a "WebDriver Sampler" in Jmeter with "HtmlUnit Driver Config". Have written a simple come, which opens a webpage. But in the back ground, there are tons of errors / warnings related to JS and CSS, present in the web page.
Something like this
2018-06-19 11:57:45,993 WARN c.g.h.IncorrectnessListenerImpl: Obsolete content type encountered: 'text/javascript'.
Some of the previous questions says its due to old JARs, but I have all latest.
1. Is there any way to solve this ?
2. Can we set logLevel in the webdriver sampler ?
No one will be able to provide answer to point 1 unless you provide the URL of the page you're trying to test.
Looking into the warning itself - it indicates a bug in your system under test as valid Content-Type for JavaScript should be application/javascript so you can raise a defect to get this fixed.
If you totally sure that the behavior is expected and there are no plans to fix these "tons of errors" you can add the next line to log4j2.xml file in "bin" folder of your JMeter installation under <Loggers> tag:
<Logger name="com.gargoylesoftware.htmlunit" level="fatal"/>
See How to Configure JMeter Logging article for more information on tuning JMeter logging subsystem.
The site works fine on Chrome/iOS/Safari/Android (you should be able to select and image and proceed to write a message on the next step). Firefox refuses to run my project's main script (you can't select an image or go forward), and gives the following error in the console:
> Content Security Policy: Directive ‘frame-src’ has been deprecated.
> Please use directive ‘child-src’ instead. (3) Unknown
It's very cryptic. I've tried the following:
1) Adding a meta tag for the CSP in the header.
Result: Creates more errors if restrictive, same amount of errors if
left to wildcards on all parameters.
2) Locally serving all scripts.
Result: I still get three unknown CSP errors. It also loads a lot
slower since the dependencies are not being loaded from a CDN.
3) Removing specific scripts.
Result: It reduces the errors by up to one, but it seems all scripts
are equally responsible. Very strange behavior.
Is this a bug in Firefox that is unsolvable? I'm tearing my hair out over this.
I needed to put listeners in $(document).ready as Firefox loads things differently as pointed out to me by Matt Gibson.
Content Security Policy did not cause the script to fail. However, it is a weird error message that gives you no information to where the error is originating, and can potentially break the site, but that is not what happened here.
My goal: I'd like to use an image from commons.mediawiki.org within a MediaWiki installation.
First I was trying to debug my InstantCommons configuration: Referring to files on commons.mediawiki.org failed for some reason. After activating various debugging options I learned that though general image download succeeded some kind of thumbnail followup request issued by the MediaWiki installation failed, which resulted into an overall error from the ForeignAPIRepo-Module.
As I can not deal with this error right now I thought I'd try something else as some kind of fallback: Download the MediaWiki image by specifiying the image URL in the upload image web page. The idea is to let MediaWiki download the image and include this image as regular wiki content. This way I would require to add license details manually and add a few comments, but this would be better than having no image.
But trying this I strangely get an error: It says "Fehler beim Senden der Anfrage" which means "Error while sending the request". But the internal request seems succeed in the logs. Here is what MediaWiki was logging:
[fileupload] Temporary file created "/tmp/URLdafce5345aa3-1"
[fileupload] Starting download from "https://upload.wikimedia.org/wikipedia/commons/c/c7/Broccoli%2C_Champignons%2C_Karotten_%2810581663524%29.jpg" <followRedirects>
[fileupload] <Error, collected 1 error(s) on the way, integer value set>
+------+---------------------------+------------------------------------------+
| 1 | http-request-error | |
+------+---------------------------+------------------------------------------+
[fileupload] Download by URL completed with HTTP status 200
Comment: All other log messages do not indicate anything that looks like an error or is related to the task of downloading the image, so I skipped them here.
The URL is correct, the image can be downloaded from the URL, MediaWiki receives a response code of 200, but instead of processing the response it indicates an error. Why? For http and https URLs I get the same result in the log.
Has anybody encountered this problem before in MediaWiki installations? Does anyone have any idea what the reason for this behaviour could be?
Comment: The wiki is of version 1.25.2 and a standard installation including SWM on an up to date standard Ubuntu Linux OS. Nothing exotic, nothing modified in any way.
Comment: Yes, I could upgrade to the latest version but, I'm not sure if this really solves the problem: I know that this featured did work in some other MediaWiki installations I have set up some time ago. Does anyone have a clue why this feature could fail here? Has anyone encountered something like this before?
Edit: I experimented with downloading from another MediaWiki instance of exactly the same version - 1.25.2 - in my local network. This did not succeed as well. But I get a different error message (translated): "The file .... could not be stored at ...". The "funny part": Though the error message indicated otherwise the file has been downloaded successfully and stored as expected. It has the correct user rights as one would expect, but log messages indicate that there are bugs in MediaWiki regarding this part: ("PHP Notice: Undefined property: UploadFromUrl::$nbytes") Maybe the uploading implementation is buggy somehow and the problems I am running into are typical?
There are multiple bugs with HTTPS support in MediaWiki, php-curl etc. See https://www.mediawiki.org/wiki/InstantCommons#HTTPS for debugging information, there is no magic bullet.
I have just upgraded from kendoui.web.2013.1.514 to kendoui.web.2013.2.716 and have noticed that in the parts of the code where I require (through require.js) a certain kendo.culture.xx-XX.min.js file that also an unsuccessful request for kendo.core.min.js happens and I get an error in the console.
This did not happen with kendoui.web.2013.1.514 and I think this part inside the kendo.culture.xx-XX.min.js files might be to blame:
("function"==typeof define&&define.amd?define:function(e,n){return n()})(["../kendo.core.min"]
Also this reference to kendo.core appears to only be present in the minified versions. Note that I already have kendo.web.min.js fully loaded and the app works fine even with the invalid request so is this a bug?
If you are using the bundles (i.e. kendo.web.min.js) then you shouldn't use RequireJS to load them or any culture files.
I'm sorry that the documentation didn't mention it, I just added a section to explain this.