I'm attempting to initiate a test transaction with sagepay by POSTing to https://test.sagepay.com/gateway/service/vspform-register.vsp
I've followed the documentation with regards to the format such a request should take, I've whitelisted my IP in the portal on the test environment and I'm using VPSProtocol=3.00 (Which are the two problems that I've seen reported to cause this) but I'm still getting a 5003 error.
I've spoken to support on the phone and POSTed to their showpost endpoint (https://test.sagepay.com/showpost/showpost.asp). It doesn't seem to be able to understand any of the details of my POST despite it being in a Name=Value format separated by &, URL encoding the values like the documentation dictates and providing all the required fields.
I've tried URL encoding the =s as well as the &s just in case I had misunderstood the documentation in that regards but it didn't make any difference.
I believe that I must be sending the body incorrectly somehow. I'd appreciate any suggestions anyone can give. The body I'm sending is below:
VPSProtocol=3.00&TxType=PAYMENT&Vendor=anyjunko&VendorTxCode=123&Amount=143.33&Currency=GBP&Description=TODO&NotificationURL=https%3A%2F%2Fstaging-nelly.anyjunk.co.uk%2Fvs%2Fsagepay-transactions%2F1%2Fsagepay-updates&BillingSurname=NameB&BillingFirstnames=NameA&BillingAddress1=1&BillingAddress2=Putney&BillingCity=London&BillingPostCode=SW11%209YZ&BillingCountry=GB&DeliverySurname=NameB&DeliveryFirstnames=NameA&DeliveryAddress1=1&DeliveryAddress2=Putney&DeliveryCity=London&DeliveryPostCode=SW11%209YZ&DeliveryCountry=GB
Update: I've now tried this with cURL and it worked correctly, but it doesn't work when I send it from Postman or from my code using akka http client.
The cURL command I used was:
curl -X POST "https://test.sagepay.com/gateway/service/vspserver-register.vsp" -d "VPSProtocol=3.00&TxType=PAYMENT&Vendor=anyjunko&VendorTxCode=123&Amount=143.33&Currency=GBP&Description=TODO&NotificationURL=https%3A%2F%2Fstaging-nelly.anyjunk.co.uk%2Fvs%2Fsagepay-transactions%2F1%2Fsagepay-updates&BillingSurname=NameB&BillingFirstnames=NameA&BillingAddress1=1&BillingAddress2=Putney&BillingCity=London&BillingPostCode=SW11%209YZ&BillingCountry=GB&DeliverySurname=NameB&DeliveryFirstnames=NameA&DeliveryAddress1=1&DeliveryAddress2=Putney&DeliveryCity=London&DeliveryPostCode=SW11%209YZ&DeliveryCountry=GB"
There are some requirements missing from the Sage Pay documentation which must be provided otherwise you will get a HTTP 500 Internal Error 5003
Documentation for Server Integration named
"SERVER_Integration_and_Protocol_Guidelines_270815.pdf" is available here:
https://www.sagepay.co.uk/support/find-an-integration-document/server-inframe-integration-documents
First make sure that you have followed the documentation to the letter, especially be careful to include all the mandatory fields and URLencode the values of the name=value pairs.
The following requirements are not mentioned in the documentation:
1 IP Addresses
The IP address from which you send your POST to ~/vspserver-register.vsp must be added to the whitelist on your account settings.
login to My Sage Pay here https://testportal.sagepay.com/mysagepay/login.msp using your administrator account (usually your vendor name)
Go to "IP Válidas" (sorry admin suite is in Spanish for some reason)
Click [Añadir] ("Add") button in bottom right
In the dialog that pops up enter your
"Dirección IP" ("IP address") - type "Whats my IP" into a Google search if you don't know it
your "Máscara de subred" ("Subnet mask") - 255.255.255.000
"Descripción" - just any name you want, has to be unique
Click [Añadir] ("Add") button
2 Firewall
Make sure your firewall is not blocking ports 80 and 443 for HTTP or SSL in either direction
3 HTTPS Protocol
Make sure that you are POSTing to the server using TLS version 1.0 or higher. Also make sure you can use one of the TLS protocols, at time of writing Sage Pay only supports these protocols
TLS1-AES-256-CBC-SHA
TLS1-AES-128-CBC-SHA
TLS1-DHE-DSS-RC4-SHA
TLS1-DHE-DSS-AES-256-CBC-SHA
TLS1-DHE-DSS-AES-128-CBC-SHA
TLS1-DHE-RSA-AES-256-CBC-SHA
TLS1-DHE-RSA-AES-128-CBC-SHA
4 HTTP Headers
There is only one HTTP header required, although it still works if you pass in extra headers such as "Host" or "Content-Length" it will fail if you do not provide exactly
Content-Type: application/x-www-form-urlencoded
Some of my users are getting the following error sometimes when they request some of the pages of my site:
Bad Request - Request Too Long HTTP Error 400. The size of the request headers is too long
It seems to happen only in Firefox.
Deleting the users cookies does help.
What I don't understand is the following: I thought that cookies are appended to every request. Why is it that only one or two of my pages show this error and most do never?
It is also not dependent on the server page. If the user requests
http://example.com/user/Myname
he might get the error.
If he just changes the capitalization of the URL it works again (like http://example.com/user/myname). (I am running IIS which does not care too much about capitalization).
For the browser the two URLs are different, for the server they aren't.
Any idea what is happening?
It seems that there were too many cookies after all. I made sure that there were not so many and it is working now.
Some of our users also ran into this same exception on IE 8 for some our our intranet sites hosted in IIS. The issue turned out to be related to using Kerberos authentication where a user belongs to many active directory groups.
We found solutions from the following Microsoft Support Articles:
HTTP 400 - Bad Request (Request Header too long)" error in Internet Information Services (IIS)
Problems with Kerberos authentication when a user belongs to many groups
The fix for us was to set the following registry keys with increased values and/or create them if they didn't exist:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxFieldLength DWORD (32bit) - assigned value data 32000 (Decimal)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes DWORD (32bit) - assigned value data 8777216 (Decimal)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters] "MaxFieldLength"=dword:00007d00 "MaxRequestBytes"=dword:0085ee00
Solution 1
delete all domain cookie from your browser
In Firefox 53
Alt -> Tools -> Page Info
Security
View Cookies
Remove All
In Chrome
check this superuser solution
Solution 2
Install Web Developer extension ( Firefox ,Chrome , Opera)
go to cookies tab -> Delete Domain Cookies like below screenshot
Solution 3
use incognito mode and see if it works for you
More details:
I had the same problem in Chrome and using a list from SharePoint.
after diagnosing with Chrome developer dashboard's network tab. I checked the headers and find the large cookie starting with the name WSS_exp and removing all of them from chrome cookie manager resolved my problem
The problem is due to a cookie that has become corrupted. The easy solution is to delete all your cookies but here is the best way to solve that specific issue, I have created a customized guide for Firefox, Chrome, and Internet Explorer. See here : http://timourrashed.com/how-to-fix-the-400-bad-request-error-message-from-a-website/
Another reason for this error stems from the user being in too many active directory groups. More modern SSRS versions do not have this problem.
It appears that the list of AD groups get passed in along in an HTTP header. Older versions of SQL Server Reporting Services have a header size limitation. So if a user is in a excessive number of groups, the easiest fix will be to remove unneeded groups.
If removing groups is not an option, you should be able to edit the web.config file and increase the limit. You can see how to do that here...
https://www.mssqltips.com/sqlservertip/4688/resolving-the-maximum-request-length-exceeded-exception-in-sql-server-reporting-services/
This answer is only in the case of using the browser Local Storage to store users' data.
Because the Local Storage has a limit of 5MB per domain, it's never cleared on its own, and there is no expiry date to remove data. When the local storage reaches the 5MB limit then starts storing data as cookies. Later, when the size of cookies reaches 1MB, the browser shows the 400 error (the size of the request headers is too long).
In this case, it is better to clear the unnecessary data from the local storage after using them.
I used ViewData instead of TempData, and issue solved.
I try to test a web-service using SOAPUI using a HTTPS endpoint. The problem is that the response message is displayed encrypted. What do I need to configure in SOAPUI in order to see the actual response message?
I tried various settings (e.g. in preferences I tried to set an exported certificate from Firefox), but no luck so far. Note that the security of the web-service is implemented using a username/password mechanism in the SOAP header and the same call works fine on a HTTP endpoint (we have a couple of environments available).
Just had this same problem and found the solution here:
http://www.eviware.com/forum/viewtopic.php?f=5&t=2601&p=10862&hilit=encrypted+response+https#p10862
Basically you need to go into file->preferences->http settings and uncheck the 'Response compression' checkbox.
I am trying to implement Google Check out (GCO) on a new server, the process seemed to work fine on the old server.
The error from GCO integration console is the timeout error you might expect if there is load on the server and/or the response takes longer than 3 seconds to respond.
To perform a test (not integrating with my database), I have set some code to send an email to me instead. If I hit the https url manually, I get the email and I can see an output to the screen. If I then leave it as that, Google still returns the Timeout error and I don't get an email. So I have doubts as to whether google is even able to hit the https url.
I did temporarily attempt to use the unsecure url for testing and indeed I received the email, however this solution isn't the route we've developed for, so the problem is something to do with the secure url specifically.
I have looked into the certificate which is a UTN-USERFirst-Hardware which is listed as accepted on http://checkout.google.com/support/sell/bin/answer.py?answer=57856 . I have also tried to temporarily disable the firewall with no joy. Does anyone have any sugestions?
Good to hear you figured out the problem.
I'm adding the links below to add a litle more context for future readers about how Google Checkout uses HTTP Basic Authentication:
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#urls_for_posting
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#https_auth_scheme
http://code.google.com/apis/checkout/developer/Google_Checkout_HTML_API_Notification_API.html#Receiving_and_Processing_Notifications
A customer sometimes sends POST requests with Content-Length: 0 when submitting a form (10 to over 40 fields).
We tested it with different browsers and from different locations but couldn't reproduce the error. The customer is using Internet Explorer 7 and a proxy.
We asked them to let their system administrator see into the problem from their side. Running some tests without the proxy, etc..
In the meantime (half a year later and still no answer) I'm curious if somebody else knows of similar problems with a Content-Length: 0 request. Maybe from inside some Windows network with a special proxy for big companies.
Is there a known problem with Internet Explorer 7? With a proxy system? The Windows network itself?
Google only showed something in the context of NTLM (and such) authentication, but we aren't using this in the web application. Maybe it's in the way the proxy operates in the customer's network with Windows logins? (I'm no Windows expert. Just guessing.)
I have no further information about the infrastructure.
UPDATE: In December 2010 it was possible to inform one administrator about this, incl. links from the answers here. Contact was because of another problem which was caused by the proxy, too. No feedback since then. And the error messages are still there. I'm laughing to prevent me from crying.
UPDATE 2: This problem exists since mid 2008. Every few months the customer is annoyed and wants it to be fixed ASAP. We send them all the old e-mails again and ask them to contact their administrators to either fix it or run some further tests. In December 2010 we were able to send some information to 1 administrator. No feedback. Problem isn't fixed and we don't know if they even tried. And in May 2011 the customer writes again and wants this to be fixed. The same person who has all the information since 2008.
Thanks for all the answers. You helped a lot of people, as I can see from some comments here. Too bad the real world is this grotesque for me.
UPDATE 3: May 2012 and I was wondering why we hadn't received another demand to fix this (see UPDATE 2). Looked into the error protocol, which only reports this single error every time it happened (about 15 a day). It stopped end of January 2012. Nobody said anything. They must have done something with their network. Everything is OK now. From summer 2008 to January 2012. Too bad I can't tell you what they have done.
UPDATE 4: September 2015. The website had to collect some data and deliver it to the main website of the customer. There was an API with an account. Whenever there was a problem they contacted us, even if the problem was clearly on the other side. For a few weeks now we can't send them the data. The account isn't available anymore. They had a relaunch and I can't find the pages anymore that used the data of our site. The bug report isn't answered and nobody complaint. I guess they just ended this project.
UPDATE 5: March 2017. The API stopped working in the summer of 2015. The customer seems to continue paying for the site and is still accessing it in February 2017. I'm guessing they use it as an archive. They don't create or update any data anymore so this bug probably won't reemerge after the mysterious fix of January 2012. But this would be someone else's problem. I'm leaving.
Internet Explorer does not send form fields if they are posted from an authenticated site (NTLM) to a non-authenticated site (anonymous).
This is feature for challange-response situations (NTLM- or Kerberos- secured web sites) where IE can expect that the first POST request immediately leads to an HTTP 401 Authentication Required response (which includes a challenge), and only the second POST request (which includes the response to the challange) will actually be accepted. In these situations IE does not upload the possibly large request body with the first request for performance reasons. Thanks to EricLaw for posting that bit of information in the comments.
This behavior occurs every time an HTTP POST is made from a NTLM authenticated (i.e. Intranet) page to a non-authenticated (i.e. Internet) page, or if the non-authenticated page is part of a frameset, where the frameset page is authenticated.
The work-around is either to use a GET request as the form method, or to make sure the non-authenticated page is opened in a fresh tab/window (favorite/link target) without a partly authenticated frameset. As soon as the authentication model for the whole window is consistent, IE will start to send form contents again.
Definitely related: http://www.websina.com/bugzero/kb/browser-ie.html
Possibly related: KB923155
Full Explanation: IEInternals Blog – Challenge-Response Authentication and Zero-Length Posts
This is easy to reproduce with MS-IE and an NTLM authentication filter on server side. I have the same issue with JCIFS (1.2.), struts 1. and MS-IE 6/7 on XP-SP2. It was finally fixed. There are several workarounds to make it up.
change form method from POST (struts default setting) to GET.
For most pages with small sized forms, it works well. Unfortunately i have possibly more than 50 records to send in HTTP stream back to server side. IE has a GET URL limit 2038 Bytes (not parameter length, but the whole URL length). So this is a quick workaround but not applicable for me.
send a GET before POST action executing.
This was recommended in MS-KB. My project has many legacy procedures and i would not take the risk at the right time. I have never tried this because it still needs some extra authentication processing when GET is received by filter layer based on my understanding from MS-KB and I would not like to change the behavior with other browsers, e.g. Firefox, Opera.
detecting if POST was sent with zero content-length (you may get it from header properties hash structure with your framework).
If so, trigger an NTLM authentication cycle by get challenge code from DC or cache and expect an NTLM response.
When the NTLM type2 msg is received and the session is still valid, you don't really need to authenticate the user but just forward it to the expected action if POST content-length is not zero. BTW, this would increase the network traffics. So check your cache life time setting and SMB session soTimeOut configuration before applying the change plz.
Or, more simple, you may just send a 401-unauthorized status to MS-IE and the browser shall send back POST request with data in reply.
MS-KB has provided a hot-fix with KB-923155 (I could not post more than one link because of a low reputation number :{ ) , but it seems not working. Would someone post a workable hot-fix here? Thanks :) Here is a link for reference, http://www.websina.com/bugzero/kb/browser-ie.html
We have a customer on our system with exactly the same problem. We've pin pointed it down to the proxy/firewall. Microsoft's IAS. It's stripping the POST body and sending content-length: 0. Not a lot we can do to work around however, and down want to use GET requests as this exposes usernames/passwords etc on the URL string. There's nearly 7,000 users on our system and only one with the problem... also only one using Microsoft IAS, so it has to be this.
There's a good chance the problem is that the proxy server in between implements HTTP 1.0.
In HTTP 1.0 you must use the Content-Length header field: (See section 10.4 here)
A valid Content-Length is required on
all HTTP/1.0 POST requests. An
HTTP/1.0 server should respond with a
400 (bad request) message if it cannot
determine the length of the request
message's content.
The request going into the proxy is HTTP 1.1 and therefore does not need to use the Content-Length header field. The Content-Length header is usually used but not always. See the following excerpt from the HTTP 1.1 RFC S. 14.13.
Applications SHOULD use this field to
indicate the transfer-length of the
message-body, unless this is
prohibited by the rules in section
4.4.
Any Content-Length greater than or
equal to zero is a valid value.
Section 4.4 describes how to determine
the length of a message-body if a
Content-Length is not given.
So the proxy server does not see the Content-Length header, which it assumes is absolutely needed in HTTP 1.0 if there is a body. So it assumes 0 so that the request will eventually reach the server. Remember the proxy doesn't know the rules of the HTTP 1.1 spec, so it doesn't know how to handle the situation when there is no Content-Length header.
Are you 100% sure your request is specifying the Content-Length header? If it is using another means as defined in section 4.4 because it thinks the server is 1.1 (because it doesn't know about the 1.0 proxy in between) then you will have your described problem.
Perhaps you can use HTTP GET instead to bypass the problem.
This is a known problem for Internet explorer 6, but not for 7 that I know of. You can install this fix for the IE6 KB831167 fix.
You can read more about it here.
Some questions for you:
Do you know which type of proxy?
Do you know if there is an actual body sent in the request?
Does it happen consistently every time? Or only sometimes?
Is there any binary data sent in the request? Maybe the data starts with a \0 and the proxy has a bug with binary data.
If the user is going through an ISA proxy that uses NTLM authentication, then it sounds like this issue, which has a solution provided (a patch to the ISA proxy)
http://support.microsoft.com/kb/942638POST requests that do not have a POST body may be sent to a Web server that is published in ISA Server 2006
I also had a problem where requests from a customer's IE 11 browser had Content-Length: 0 and did not include the expected POST content. When the customer used Firefox, or Chrome the expected content was included in the request.
I worked out the cause was the customer was using a HTTP URL instead of a HTTPS URL (e.g. http://..., not https://...) and our application uses HSTS. It seems there might be a bug in IE 11 that when a request gets upgraded to HTTPS due to HSTS the request content gets lost.
Getting the customer to correct the URL to https://... resulted in the content being included in the POST request and resolved the problem.
I haven't investigated whether it is actually a bug in IE 11 any further at this stage.
Are you sure these requests are coming from a "customer"?
I've had this issue with bots before; they sometimes probe sites for "contact us" forms by sending blank POST requests based on the action URI in FORM tags they discover during crawling.
Presence and possible values of the ContentLength header in HTTP are described in the HTTP ( I assume 1/1) RFC:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
In HTTP, it SHOULD be sent whenever the message's length can be determined prior to being transferred
See also:
If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
Maybe your message is carrying a Transfer-Encoding header?
Later edit: also please note "SHOULD" as used in the RFC is very important and not equivalent to "MUST":
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Ref: http://www.ietf.org/rfc/rfc2119.txt
We had a customer using same website in anonymous and NTLM mode (on different ports). We found out that in our case the 401 was related to Riverbed Steelhead application used for http optimization. The first signal pointing us into that direction was a X-RBT-Optimized-By header. The issue was the Gratuitous 401 feature:
This feature can be used with both per-request and per-connection
authentication but it‘s most effective when used with per-request
authentication. With per-request authentication, every request must be
authenticated against the server before the server would serve the
object to the client. However, most browsers do not cache the server‘s
response requiring authentication and hence it will waste one
round-trip for every GET request. With Gratuitous 401, the client-side
Steelhead appliance will cache the server response and when the client
sends the GET request without any authentication headers, it will
locally respond with a ―401 Unauthorized‖ message and therefore saving
a round trip. Note that the HTTP module does not participate in the
actual authentication itself. What the HTTP module does is to inform
the client that the server requires authentication without requiring
it to waste one round trip.
Google also shows this as an IE (some versions, anyway) bug after an https connection hits the keepalive timeout and reconnects to the server. The solution seems to be configuring the server to not use keepalive for IE under https.
Microsoft's hotfix for KB821814 can set Content-Length to 0:
The hotfix that this article describes implements a code change in Wininet.dll to:
Detect the RESET condition on a POST request.
Save the data that is to be posted.
Retry the POST request with the content length set to 0. This prevents the reset from occurring and permits the authentication process to complete.
Retry the original POST request.
curl sends PUT/POST requests with Content-Length: 0 when configured to use HTTP proxy. It's trick to overcome required buffering in case of first unauthorized PUT/POST request to proxy. In case of GET/HEAD requests curl simply repeats the query. The scheme for PUT/POST is like:
Send first PUT/POST request with Content-Length set to 0.
Get answer. HTTP status code of 407 means we have to use proxy
authorization. Prepare headers for proxy authentication for send request.
Send request again with filled headers for proxy authentication and real data to POST/PUT.