Microsoft.AspNetCore.Http.StatusCodes contains lots of status code constants useful for returning from a controller and can for example be used like this in a controller:
return StatusCode(StatusCodes.Status201Created);
But oddly the StatusCodes class contains no value for 422 Unprocessable Entity, at least not in Asp.Net Core 1.0.1. Why doesn't it contain StatusCodes.Status422UnprocessableEntity ?
Has this http status code been depreciated by some spec I am unaware of? Or is there some other reason that 422 Unprocessable Entity wasn't included?
Actually it is included in Microsoft.AspNetCore.Http.StatusCodes.
Please find current list in: StatusCodes.cs
HTTP Status Code 422 is WebDAV specific (RFC 4918) and it was added to Microsoft.AspNetCore.Http.StatusCodes a little bit later.
(See details of Added HTTP Status codes #654 pull request)
But it was a few months ago, so the question is what version of ASP.NET Core are you using?
Update:
As Ron C noticed - this status code is included in v1.1 (and not available in v1.0.1).
I wouldn’t know why but I did a quick search and found this post.
As of 2015, #Tom Christie mentioned the following:
Behaviorally both 400 and 422 response codes will be treated the same
by clients and intermediaries, so it actually doesn't make a concrete
difference which you use.
And this:
422 Is specifically a WebDAV extension, and is not referenced in RFC
2616 or in the newer HTTPbis specification.
Maybe...just maybe...the reason why the status code 422 isn’t part of the Microsoft.AspNetCore.Http.StatusCodes might be because it is a WebDAV extension but don’t take my word for it as I’m only trying to raise awareness as to what could be the cause.
Related
I am busy with implementing payments using Sage Pay direct protocol 3.0
(4,0 unavailable yet as I understand)
I register transaction using vspdirect-register.vsp
I redirect user to ACSURL with MD, PAReq and TermUrl using POST
I catch user on TermUrl and check transaction status using direct3dcallback.vsp with MD and PARes
BUT on this stage I always get:
STATUS: 'OK'
AVSCV2: 'ALL MATCH',
StatusDetail: '0000 : The Authorisation was Successful.',
AddressResult: 'MATCHED',
PostCodeResult: 'MATCHED',
CV2Result: 'MATCHED',
'3DSecureStatus': 'ERROR'
Using MySagePay tools I get an explanation like :
3D secure status The authentication callback message was MALFORMED. No 3D-Authentication occurred! ERROR
Attempt 1
ECI result Unknown result type
How can I debug this error?
Is it normal that I get status OK even when 3DSecureStatus : ERROR ?
Q1: Why are you getting a 3-D Secure error?
The MALFORMED status points towards SagePay not being able to read your request .. (e.g it's syntactically or structurally invalid etc).
Given the lack of code in the OP, rather than try and guess what you're doing wrong, I'll instead show what we do (which works - we've implemented both v3.00 & 4.00).
We perform an HTTP POST with the following parameters to https://live.sagepay.com/gateway/service/direct3dcallback.vsp (or https://test.sagepay.com/gateway/service/direct3dcallback.vsp in the case of testing):
For direct protocol v3.00
VPSProtocol: "3.00"
MD: MD posted to TermURL (e.g 20156570522002324295)
PARes: "PARes posted to TermURL"
For direct protocol v4.00
VPSProtocol: "4.00"
VPSTxId: VPSTxId from the initial payment response (Note that curly brackets {} need to be removed!!!)
CRes: "CRes that was posted to the ThreeDSNotificationURL"
Q2: Why do you get an OK status when 3-D Secure failed?
I believe this is probably due to your merchant ruleset. You can state what you want to happen with the transaction if 3-D Secure is unavailable or fails.
So, check your ruleset. I believe that we force our consumers through 3-D Secure as our chargeback percentages were quite high otherwise.
Footnote
I would also concur that since you are doing this work, it would probably be more beneficial to implement version 4.00, since that means the majority of your customers should have a better experience, and you'll have a better conversion rate too. Win win.
HTH.
Protocal 4.0 is available on the SagePay test server and you can start working on that already. It needs to be implemented by the 14th of September 2019 and the last info I've got from SagePay support staff is that the protocal 4.0 will be on the live server by the 14th of September 2019.
To your probelm: I call the ACSURL with the added query string for MD, PaReq, TermUrl which works ok.
I see that you posted PAReq. Please note that I use PaReq. A small a instead of a capital A. See page 16 of the Documentation. DIRECT_Integration_and_Protocol_4_Guidelines.pdf
Maybe you could post the complete URL you post to SagePay.
Hope this helps.
Thanks guys!
Sage support have helped me to find issue.
The point was - route 'ThreeDSNotificationURL' make changes in 'CRes' as we have configured some security behaviors, and when we check this key on Sage side - we got an error. so some extra security behaviors for this route have solve the issue.
Thanks guys!
I am trying to make a POST request to an endpoint served using jetty server. The request errors out saying 413 Request entity too large. But the content-length is only 70KB which I see is way below the default limit of 200KB.
I have tried serving via ngnix server and add client_max_body_size to desired level but that didn't work. I have set the setMaxFormContentSize of WebContext and that didn't help either. I have followed https://wiki.eclipse.org/Jetty/Howto/Configure_Form_Size and that didn't helped me either.
Does anyone have any solution to offer?
wiki.eclipse.org is OLD and is only for Jetty 7 and Jetty 8 (long ago EOL/End of Life). The giant red box at the top of the page that you linked it even tell you this, and gives you a link to the up to date documentation.
If you see a "413 Request entity too large" from Jetty, then it refers the the Request URI and Request Headers.
Note: some 3rd party libraries outside of Jetty's control can also use HttpServletResponse.sendError(413) which would result in the same response status message as you reported.
Judging by your screenshot, which does not include all of the details, (it's really better to copy/paste the text when making questions on stackoverflow, screenshots often hide details that are critical in getting a direct answer), your Cookie header is massive and is causing the 413 error by pushing the Request Headers over 8k in size.
We are rewriting an old integration with a service from python to golang. This service uses Custom status codes. For example the status code is 8000. But while I am trying to get the response it is giving me error as “malformed HTTP status code”. Can some one help me to resolve this issue. Gone through the code and found the following piece of code that throws the error if the status code is not having length of 3.
if len(statusCode) != 3 {
return nil, &badStringError{"malformed HTTP status code", statusCode}
}
EDIT:
I do understand the RFC standard for HTTP status is 3 digits. But I am re-integrating a legacy code of a Banking system. So I cannot / dont have the access to change the service's implementation.
To give more context, python's http library was not doing this validation. (I am not saying that One language is superior to another, so please dont compare the languages/libraries) So wondering if there is any way to bypass this particular validation.
Thanks in advance for understanding..
If you wish you may use standard code for general information (ok, client error, server error, etc) and custom application codes transferred in payload for more details.
From RFC 2616:
The Status-Code element is a 3-digit integer result code of the
attempt
What you have there is not valid HTTP. If you can get hold of the socket directly, you could try parsing the raw TCP data.
I'm a bit confused on HTTP status code. Let's say someone calls an endpoint like .../person/15 but there isn't actually a person with identifier 15.
I was previously returning a 412, but as I read that status code closer that's supposed to be related to headers.
That would be 404 (Not Found). If you’re able to detect that the person has been deleted (and their id won’t be reused), use 410 (Gone).
The HTTP status code you may want to use is HTTP/1.1 404 Not Found. There is also a very usefull list with all these codes:
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
The folk in the QA department use visual studio team test (2008 IIRC) to run load tests against our web application.
The latest set of tests have failed on several pages. The error reported is
Request failed: The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF
Searching for this using google yields quite a few results. it would appear that this error message is generated from the .Net framework WebRequest class (i.e. it is not a visual studio specific message). The most useful result is this one, which details my exact problem and how to suppress the error.
But of course, I want to get to the bottom of why this error occurs in the first place. Here are some more facts: -
This error never used to occur when the tests were run against an older version of the web app. The web app. host OS and web server (Win 2003 and IIS 6) are identical in both cases.
Not all the pages generate this error - only some.
The only significant change to these pages (that I can think of) is that they now use some AJAX whereas before they did not (IIRC)
In order to narrow down the problem, I created the simplest page that I could to replicate the problem. Luckily, that was not too hard. I then inspected the bytes in the header using Fiddler but I could not find an occurrence of a CR (0x0D) that was not followed by a LF (0x0A).
The raw HTTP response (as stored from Fiddler by response saving bytes - so its encoding should not have been altered during the save) is here as text if you don't believe me!
So now I am left thinking that the supposed error might be a false alarm. Does anyone else have experience of this/can help shed light?
This is definitely not a false alarm - I've been getting this error in my app a lot while trying to communicate with Facebook API.
I've just stumbled upon this response from Steven Cheng - http://www.velocityreviews.com/forums/t302174-why-do-i-get-the-server-committed-a-protocol-violation.html - and let me quote him:
From your description, you're using
the HttpWebRequest component to send
some http request to some external web
resource in your ASP.NET web
application. However, you're always
getting the "The server committed a
protocol violation.
Section=ResponseStatusLine" error
unless you set the following section
in the web.config file:
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
And you're wondering the cause of this behavior, correct?
As for this issue, I've performed some
research on this and found that the
problem is actually caused by the
critical http header
parsing/validating of the
HttpWebRequest component. According to
the Http Specification(http1.1), the
HTTP header keys shoud specifically
not include any spaces in their names.
However, some web servers do not fully
respect standards they're meant to.
Applications running on the Dotnet
framework and making heavy use of http
requests usually use the
httpWebRequest class, which
encapsulates everything a web oriented
developer could dream of. With all the
recently issues related to security,
the "httpWebRequest" class provides a
self protection mechanism preventing
it to accept HTTP answers which not
fully qualify to the specifications.
The common case is having a space in
the "content-length" header key. The
server actually returns a "content
length" key, which, assuming no spaces
are allowed, is considered as an
attack vector (HTTP response split
attack), thus, triggering a "HTTP
protocol violation error" exception.
Will try if this helps right now and post results later