I'm getting HTTP Status 405 – Method Not Allowed: "The method received in the request-line is known by the origin server but not supported by the target resource."
when I'm making the following REST API call
https://myantserver.example:5443/WebRTCAppEE/rest/v2/broadcasts/{id of my stream}/recording/true
Not sure what I'm doing wrong... Is there any setting I need to configure? The streams get saved just fine if i enable "Record Live Streams as MP4"
But I want to only record specific streams. If there was any way to "Record all livestreams where the stream ID includes a specific string" that would work as well.
Any suggestions appreciated, Thanks!
Solved it, the problem was that I was making a POST request instead of a PUT request
Related
I have a DB table with a report_url column. As soon as a backend done with filling and storing a report it fills that column with S3 link. If the report was not yet stored, the column value is NULL by default. I also have Pyramid API where an endpoint is declared returning Response with body of report content. So, whenever the user makes request, according controller will be fired to get the report link and download the file and return it to user. However, if report is not done yet (report_url is NULL), I need to inform the user somehow. In this case front-end should receive HTTP status 400, but I have not figured out if this fits best. Or maybe 503 fits better here?
Have a look at available http status codes.
What you probably want is 404, specifically because of this line:
In an API, this can also mean that the endpoint is valid but the
resource itself does not exist.:
Full description:
404 Not Found
The server cannot find the requested resource. In the browser, this
means the URL is not recognized. In an API, this can also mean that
the endpoint is valid but the resource itself does not exist. Servers
may also send this response instead of 403 Forbidden to hide the
existence of a resource from an unauthorized client. This response
code is probably the most well known due to its frequent occurrence on
the web.
If the server is working on getting the report, 102 gets an honorable mention:
102 Processing (WebDAV)
This code indicates that the server has received and is processing the request, but no response is available yet.
it's not part of the standard, it's an extension, WebDAV.
400 status codes are used to let the user know something they did is not working. 500 status codes are used when something is going on with the server. That's how I understand it anyway.
In that way, if this is a "normal" execution of the API/program, perhaps a 200 status code would do just fine. E.g. just define the endpoint to return {"report_url": null} if it isn't ready, otherwise {"report_url": "an actual url"} and then give 200 in each case. And the receiving party handles it depending on if it is null or not. The pro of this method is, now the user can know that it is definitely a proper endpoint (and not an url typo, which would also give 404). However, you could make your own 404 page saying "report is not ready" or "report does not exist" for example. The con of this 200 method is some speed penalty since you have to send an unnecessary response body.
Disclaimer: I am not a web/http expert at all.
The correct HTTP status code is 202 - Accepted. The documentation says:
The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed.
..
The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.
I have a problem with the x-csrf-token validation with regard to a HTTPS-Post-Request. The request comes from a Lambda function triggered by an Amazon Alexa skill and is sent to a XSO Data file running on the SAP Cloud Platform in an SAP HANA Database. I use Javascript/Node.js.
A valid token is set in the request header (see code in the first picture below) but the response header shows for the x-csrf-token "required" (see code in the second picture below). So there is an error with the validation. The same post request with POSTMAN works correctly, but when I try it via a JS File as a Lambda function (in the first picture) there it comes this error with HTTP status code 403 (see code in the second picture below). The POST request itself does work, but the token validation not. GET requests work fine.
Does anybody know a possible solution?
Thank you very much!
1.picture: request
2.picture: response
Please try to get the csrf token first before setting it to the request body. CSRF token changes from device to device as well as the timeframe. I also had a similar issue, and upon implementing the above solution, it started working perfectly.
I am writing this as a separate answer as I had an issue in Spring Boot RestTemplate call. I could arrive at a solution after going through this article.
SAP CSRF Issue
Basically the "set-cookie" header is instructing the browser to set the "Cookie" header. All one has to do (apart from x-csrf-token) is to replace the comma in the string of the cookie with a semicolon. Then set the header "Cookie" to this replaced value;
We have exposed a HTTP endpoint with POST method. To make a successful call the clients has to make the POST call with a request body and other required parameters.
When we hit the endpoint directly in the browser the response says 200 OK. Its a GET call. there is no implementation for GET.
The question is - an endpoint which supports only POST should throw an error while hitting directly on the browser with a GET ?
What should be the best error. Do we have to handle this in GET saying GET is not appropriate method on this end point?
Or is it correct to leave the GET response as 200 OK - to make the clients feel the end point is up and running?
If you're asking about what an HTTP server SHOULD do... the answer is: it has to implement GET and HEAD. See RFC 7231.
I am using webMethods from the SAG and it seems if the service
pub.client.http
throws an exception on status code 401 "Unauthorized".
This leads me to the problem that I cannot handle the status code because nothing is written to the pipeline.
getLastError
does contain the string "Unauthorized" but not the status code.
Except that I do not want to start parsing exception messages...
Any ideas?
The output parameter header from the pub.client.http call should contain the information you’re after:
header Document Conditional. HTTP response headers.
Key Description
lines Document Fields in the response header, where key names represent
field names and values represent field values.
status String HTTP status code of the response.
statusMessage String HTTP status message of the response.
See the webMethods Integration Server Built-In Services Reference page 122 for more details.
Asked a SAG senior consultant.
This is the normal behavior.
There is no flag which you can set to enforce suppression of this exception...
You can suppress the exception and have the HTTP 401 status returned like any other HTTP response. Go to the IS Admin Extended Settings and set:
watt.net.http401.throwException=false
Note this is a server-wide setting, so it will affect all your applications/services that use pub.client:http.
According the comment from #Hugo Ferreira probably there are ACL restriction whether inside your webMethods environment, or your client URLs.
Things you should consider:
Do your webMethods server located inside closed environment wherein need to get connected to proxy to get to the outgoing request. Which is likely you can investigate by run web-browser program directly from your wM server towards the URL address (i.e using SSH to run firefox in my case and popup appeared)
The client that your request will go to, have HTTP for authentication requests
Solution
To pass this all you need to do is input the auth user/password or any other auth mechanism i.e kerberos, token, etc. inside the pub.client:http
I use the SoundCloud API to retrieve the stream URL for a streamable track.
I follow the redirect and I end up with an URL that looks like:
http://ec-media.soundcloud.com/eodihgiuh.128.mp3?<a string>
AWSAccessKeyId=<access key>
&Expires=<timestamp>
&Signature=<signature>
or
http://ak-media.soundcloud.com/euieuieie.128.mp3?
AWSAccessKeyId=<access key>
&Expires=<timestamp>
&Signature=<signature>
&__gda__=<a string>
Then I start streaming the MP3 data at this URL.
First I send a HEAD request to read the Content-Length header, so that I know how many GET requests I will have to send in order to play the whole song.
Then I send several partial GET requests, each one with a different Range header.
The problem is that sometimes the HEAD request returns a 403 status code, even though a GET request to the exact same URL returns with a 200 status code. It seems that this happens if and only if the host is ak-media.soundcloud.com.
Is this supposed to happen? I expected the HEAD request to return exactly the same headers as the GET request, only without the body response.
Cheers,
PB
P.S: I should probably mention that my code is not running on a computer, but on an audio device with a tiny 8-bit processor which has extremely limited resources.
Unfortunately, currently we only offer guaranteed proper response for GET requests.
As a hack, you could try to do requests with very short ranges.