I have been using WinHTTP API functions from PowerBuilder 10 and it works really well except that the WinHttpConnect function does not return an error when the URL is bad. If I pass an empty string for ServerName then the returned handle is zero but GetLastError is zero as well.
If I am reading the documentation correctly, the returned handle should be zero if the ServerName is bad and there should be an error code from
I am currently on Windows 8.1 but I have seen this on XP and 7.
Related
I'm making a request that works great and acts as supposed to. The actual authorization is provided using headers and working as expected too. This is the URL of it.
https://localhost:44385/api/security/check
By coincidence, I happened to replace the verbatim string check with the actual token, so the URL changed to
https://localhost:44385/api/security/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ...
All in all, the token happens to be 475 characters long. Then, when executing that call, I get the error message as follows.
Error: connect ECONNREFUSED 127.0.0.1:44300
I don't understand the issue and the status code 400 tells me only that the request is bad. Is it purely due ot the length of the URL? It seems like a bit too short (although there is a limitation for that but we're talking about a few thousands characters)...
The signature of the receiving method in the controller looks like this. It resides in the controller with path Security.
[HttpHead("{check}"), Authorize]
public IActionResult IsAuthorized(string check) { ... }
I also tried GET instead of HEAD with the same result. It's difficult to learn more about the error based on 400 Bad request only. It's a bit like something went wrong somewhere kind of error.
After some experimenting, I can confirm that it's not the length of the URL as such but rather the length of the segment between slashes. The first request works, the other does too but the third doesn't. The xxx part is precisely 260 characters and **yyy* part is precisely 261.
https://localhost:44385/api/test/xxx
https://localhost:44385/api/testtest/xxx
https://localhost:44385/api/test/yyy
What is this about?! It's like string in a method in my WebAPI can't be longer than 260 characters. Not 256, which at least would make some kind of sense...
Googling gave a veeery wide range of vastly spread hits and gave me nothing that I could relate to. Postman provides pretty much the same, limited information. The browser's network tab give even less.
A bit confused how to get to know more, how to diagnose it further and/or what to google for. Since it's a non-problem for the production environment, I can't bother my colleagues - the question is purely academic.
The limit you're hitting is UrlSegmentMaxLength (260).
This is all the way down in Http.Sys and only configurable in the
registry.
https://support.microsoft.com/en-us/help/820129/http-sys-registry-settings-for-windows
Workaround: break it up into multiple path segments, or move it to the
query or body. Or use Kestrel without IIS.
Resource: https://github.com/aspnet/AspNetCore/issues/2823#issuecomment-360921436
Here's a related post:
Setting UrlSegmentMaxLength from commadline
Trying to integrate ApplePayJS into my website and getting this annoying message::
InvalidAccessError Code 15
"The object does not support the operation or argument"
Everything seems to have been going well and now nothing works.
If you get this error, in my experience Safari is now dead to ApplePayJS and you must start by force quitting and reopening it again.
Turns out the reason for me what that the ApplePay API completely craps out if you pass a string instead of an object into the completeMerchantValidation.
If what you return from your server is not JSON object, but a string instead then you can do this:
session.completeMerchantValidation(JSON.parse(merchantSession));
Or better still - fix your server to return a JSON object instead of a string.
Update 4 years later:
I just saw this again today for a real customer as opposed to during my own testing. In this instance the order had succeeded and the customer thought it had failed so attempted to go through the process again.
Oddly it was on this call with the same error "The object does not support the operation or argument."
applePayTokenize.session.completePayment(ApplePaySession.STATUS_SUCCESS);
Since the payment succeeded I've changed my logic to just ignore the exception (for STATUS_SUCCESS only) and proceed to the final page. I don't even know if the ApplePay sheet was still open but even if it was at least when it cancels it will be on the receipt page.
I have also had this issue but with a different reason
Your domain name in the session needs to equal the domain name of your browser. you set the domain name in the backend during in the initiativeContext
https://developer.apple.com/documentation/apple_pay_on_the_web/apple_pay_js_api/requesting_an_apple_pay_payment_session
I have a custom action which is used to elevate users to be able to log on as a service. This gets run during the installer. It works fine for years on every Windows operating system up until Windows Server 2012. When the below code is run on this version of Windows instead of getting a long back of 0 for success I get a different error code back.
LsaAddAccountRights(
IntPtr PolicyHandle,
IntPtr AccountSid,
LSA_UNICODE_STRING[] UserRights,
long CountOfRights)
The problem is the code appears to be different every time and is a very large number, e.g. 102938473.
I run the error code through the following method to get the error code but this returns a different large number which doesn't appear to be a valid error code.
LsaNtStatusToWinError(long status)
I have tried looking these error codes up, but with no luck. They seem to be randomly generated and nonsensical.
If I ignore the returned error code, It appears that the user is successfully allowed to log on as a service. So everything appears to be working, except I am getting an error code back. I could ignore this error code, but what happens when it is a valid error, I may ignore it in the future.
Extra Information
I can run the code that is in the Custom action fine on its own in a console application without error. Only when it is part of the wix installer it seems not to work.
I'd take a look at the WiX Util extensions's User element. The name attribute can be a property. Using the CreateUser, LogonAsService and UpdateIfExists attributes you can take an existing account and grant it the rights. Or perhaps you have more code that you can refactor.
Issue could be with the return type of LsaAddAccountRights in C#.
I was able to solve the issue by changing the return type of LsaAddAccountRights in C# from long to UInt32. Found this information here . This change must be done for LsaNtStatusToWinError and LsaClose as well.
I am writing a iOS client for a an existing product that uses a legacy SOAP webservice. I got the proper URL to send my SOAP/XML messages too and even have some samples. However, none of them seem to work...
I always get a 404 error with the following error text "Predicate mismatch for View"
I am using an ASIFormDataRequest for the actual request and apending the data (SOAP XML in this case) via [someFormRequest appenData:myData].
I am flat out of ideas here and am wondering what, if anything I am doing wrong. Or should I ping one of the back end guys? Could this error be a result of something on the server side?
This is an error message spit out by the pyramid web framework when attempting to access a URL without supplying all of the required parameters. You definitely want to double check that the URL you are using has all of the required params (headers, query string options, request body, etc) and if you're convinced that what you are sending is correct then but your backend guys because it's definitely a miscommunication or a bug between the two of you.
Simply put my code is working fine and returning JSON from GET requests, but when there is a space in one of the value pairs of the QueryString the Service shuts down. Even when debugging in the IDE no exception is thrown, although, using Fiddler to perform the GET request I get back a "HTTP Error 400 - Bad Request" - probably because the server's just shut down (the Visual Studio development Server).
Spaces aren't a legal part of the querystring, and should be replaced with a + (plus sign)