I use AB(ApacheBench), Version 2.3.
I'm trying to test "http://localhost/myPage" with Basic Authentication.
There isn’t any problem when I use web browser like I.E.
The apache’s log message shows HTTP response code changing 401->301->200.
It saied my http request was finished successfully.
But when I use AB , result is different .
AB saied request was completed but Apache’s log shows status has stopped at 301.
Now,My question is how to get AB follows to redirect 301.
Based on my research AB doesn't follow redirects. I haven't checked the source code but I did a fair share of testing and googling around. My testing involved running AB tests and checking the access log. I was able to get redirects working with wget.
At one point I gave up on AB and installed siege instead, see http://www.joedog.org/siege-home/ for more details.
Turns out "localhost/myPage" isn't correct path. I should have instead included a "/" at the end of URL like "localhost/myPage/". Now AB follows redirect 301.
Related
One of my old website is running TYPO3 v4.5.
I bought a SSL certificate and my sys admin installed it on the server.
the front-end is running well on https
tha back-end login form runs weird : one time my login/password are ok, but sometimes it doesn't allow me to enter the back-end.
It is totally random and in Firebug, I have no clue in the console or in the network tab to help me. Same behavior for Chrome, FF or IE.
I tried a lot of parameters :
[BE]LockSSL = 1
[SYS][reverseProxyIP] with " ... "
[SYS][reverseProxySSL] with " * "
[SYS][cookieSecure] = 1
I event tried a lot of different combinations, with no success.
Please notice that I also get a TYPO3 6.2 website and those parameters work perfectly on it. I guess that I am missing somthing for v4.5 ?
Check the BE cookieDomain configuration!
I came across 404 error a few times and i have difficulties in debugging this kind of problem.
What is the strategy and tools available to analyse such problems (firebug, logs...).
How to differentiate and fix the cause ?
page not existing ,wrong path , redirection and rewriting ,server problem ...
404 error code means that a file is not found for whatever reason.
Just check that the file exists and that the path you use is right.
You can analyse sent requests and received responses headers and body in your browser's developper console if you want more details about why some request failed.
A lot of people have ask this question but it was 2 month ago with another gitlab version,
I'm using gitlab 5.2 in a fresh debian 7.0 serveur
everything looks Okay on the website but when I run /home/git/gitlab-shell/bin/check I've got this error :
Check GitLab API access: FAILED. code: 302
Check directories and files:
/home/git/repositories: OK
/home/git/.ssh/authorized_keys: OK:
I'm running on a custum ssh port but I'm able to connect.
When pushing I've got this error:
git push -vu origin master
Pushing to ssh://git#apps.ndd.fr:2232/Users/test.git
fatal: The remote end hung up unexpectedly
Thanks for your answers!
I've just got the same error and go look onto the code.
The thing I've found the gitlab_net module going for answer at #{host}/check (gitlab-shell/lib/gitlab_net.rb)
host method is defined as "#{config.gitlab_url}/api/v3/internal", and at the same time config.gitlab_url defined in ./gitlab-shell/config.yml "Should end with a slash" (c) So my web server just returns 302 on a request to remove double slashes.
FYI: That fail is about API and not about web service. So it's non-critical in many cases anyway.
I think it's a minor bug in code and there is a close issue to this: https://github.com/gitlabhq/gitlabhq/issues/3483
We've got an instance of Magento developed (two, in fact, since we tested both 1.6 and 1.7), and we are unable to have stamps.com hit its API. I've checked all the logs in our reverse proxy as well as Apache, and the connection is made, is successful, and it closes OK — so nothing's getting blocked. However, the API call times out, and we get this error when it hits the ShippingZmagento.php:
<Error>
<Code>1</Code>
<Description>Please, make sure that you use right URL. Url is case sensitive</Description>
<MessageDetails>http://mysubdomain.mydomain.com/index.php/api/soap/?wsdl</MessageDetails>
<Version>3.0.0.55618</Version>
</Error>
The FQDN is correct, and I'm about to hit the WSDL directly just fine as well — so it seems like a bad address translation might be happening at the API level or something.
We've tried it out in the DMZ with a couple of test domains (both with domains and subdomains), to no avail.
Any thoughts any of you might be able to shine on this would be most appreciated. Thanks in advance!
Open up stamps.com's php files and search for wsdl references they will need to updated to work on 1.7 magento:
What is SOAP V2 url on Magento 1.7.0.0
I am using a java raw HTTP client to connect to Shopify API (specifically, using Play Framework with the non-defualt sync driver which is actually the JDK's default driver).
My application usually manages to connect successfully and convert the temporary access token into a permanent one by calling the /admin/oauth/access_token endpoint.
However, sometimes I get this error result from the API:
Generic Error(400)
{"error":"invalid_request"}
I haven't been able to reproduce the issue with my test stores - I've tried installing a fresh store, reinstalling existing stores after uninstalling, I'm not sure why this call sometimes fail and how to debug it. The API call still continues to succeed for some stores using our application.
Some things that I am doing:
Even if the URL of the store is on a custom domain, I'm always using the https://foo.myshopfiy.com/admin/oauth/access_token URL and not the URL of the custom domain, to prevent a redirect.
I am always using an https URL and never an http one, again to prevent a redirect (we noticed a few issues with redirect with the Java HTTP client, so we aim to have zero redirects)
A thread I found about this error suggest possible problems with our SSL certificates, however I don't think this is my problem because some requests work for us, and the result of running openssl on our machine does't show any issues.
How should I proceed? Open a support ticket with Shopify?
FYI, I see that this specific problem only started yesterday on Feb 19 2013, so it might be a temporary issue.
FYI, the problem was caused by reusing a temporary access code.
Our fault - Shopify could have been more clear in their error message though.