I have UAC that registers to a UAS, after registration the UAS sends me an OPTIONS request, what should I answer it?
only the audio media streams?
Update I:
Allow me to explain myself better... if I want to invite someone to a session I USE the INVITE method and negotiate the media then, for that specific session. But once I register to the server, and it asks me for OPTIONS, then what should I supply, everything my client supports? once I answer it would it deduce that every INVITE I would request from now on would use these medias? or would I need to supply new media with every request?
Update II:
Hi Wiz,
I was in the process of building a negotiation system, so i tried it out and replied the UAS here is the sort dialog we had:
OPTIONS sip:310#hostName.hn SIP/2.0
Via: SIP/2.0/UDP xx.xx.xx.xx:5060;branch=z9hG4bK45b197cb;rport=5060;received=xx.xx.xx.xx
From: "Unknown" <sip:Unknown#xx.xx.xx.xx>;tag=as66cf26df
To: <sip:310#hostName.hn>
Contact: <sip:Unknown#xx.xx.xx.xx>
Call-ID: 28803f304694e9ac61f6455a0b71795e#xx.xx.xx.xx
CSeq: 102 OPTIONS
User-Agent: Freeswitch 1.2.3
Max-Forwards: 70
Date: Sat, 05 Jun 2010 12:06:43 GMT
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Supported: replaces
Content-Length: 0
OPTIONS In Response To 102:
SIP/2.0 200 OK
Via: SIP/2.0/UDP xx.xx.xx.xx:5060;branch=z9hG4bK45b197cb;rport=5060;received=xx.xx.xx.xx
From: "Unknown" <sip:Unknown#xx.xx.xx.xx>;tag=as66cf26df
To: <sip:310#hostName.hn>
CSeq: 102 OPTIONS
Call-ID: 28803f304694e9ac61f6455a0b71795e#xx.xx.xx.xx
Allow: INVITE,CANCEL,ACK,BYE,OPTIONS
Content-Type: application/sdp
Content-Length: 248
v=0
o=310 4515233118481497946 4515233118481497946 IN IP4 10.0.0.1
s=-
i=Nu-Art Software - TacB0sS VoIP information
c=IN IP4 10.0.0.1
m=audio 40000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
This response caused the server to stop sending me the options request, does this means I can only use these parameters with the server now? or as you said, it does not matter?
Thanks,
Adam.
An OPTIONS request can be used to query a SIP device for capabilities so yes by the letter of the law you should return all supported codecs in the OPTIONS response SDP.
One thing to keep in mind is that some user agents, particularly Asterisk, use OPTIONS requests as a keep-alive mechanism and they don't actually care about the response and in fact simply drop it. If processing an OPTIONS request is going to to cost you a bit of processing time keep that fact in mind.
On my own SIP Proxy I return a 405 Method Not Supported for OPTIONS requests and have never had any side effects.
You should return the same status as you would for an invite.
Besides your SDP (again same as an invite would) you should use Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields.
Read more: http://www.faqs.org/rfcs/rfc3261.html#ixzz0pnjJjKfl
Related
I am currently debugging a surprising "Bad Request" response from an API.
Request:
POST /path HTTP/1.1
...
Response:
HTTP/1.1 421 Misdirected Request
Date: Fri, 30 Nov 2018 21:59:12 GMT
...
Via: https/1.1 subdomain.example.org (ApacheTrafficServer/7.1.4)
...
Per my research, HTTP status code 421 was only added with the http/2 specification. As you can see, my client is sending a HTTP1.1 request.
Does it make any sense to use it in the response to a HTTPS/1.1 request? What could it mean there?
Update: Further research indicates that this 421 response is triggered by an invalid CSRF token and Cookie value in the header, retrying the request with a verifiable valid combination returns the expected result with 200 OK. Unfortunately this doesn't really explain anything.
421 was added for HTTP/2 which allowed connection reuse. If a client reused a connection incorrectly (like Firefox used to) then the server should respond with this.
However that doesn’t mean it’s an HTTP/2 only status code. For example if a load balancer takes HTTP/2 requests in and passes them to back end servers over HTTP/1.1, then one of those backend servers can reject a request over HTTP/1.1 if it believes it was incorrectly sent that request. As you can see your request was sent via an Apache Traffic Server, so I suspect that is what happened here.
i am trying to send request from my localhost to ebay servers , i am using postman to do so.
the request is the same request which this ebay page send http://www.fees.ebay.com/feeweb/feecalculator
when you press on the calculate fees button .
the request should return json response, but i am unable to do that in my postman , please find my request bellow:
how ebay can identify that my response is not ajax request ?
POST /feeweb/calculate HTTP/1.1
Host: www.fees.ebay.com
X-Requested-With: XMLHttpRequest
Referer: http://www.fees.ebay.com/feeweb/feecalculator
Accept: */*
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
locale=en_US_MAIN&catlevel1=2984&dp_cat-level1=Baby&catlevel2=20394&dp_cat-level2=athing+%26+Grooming&catlevel3=113814&dp_cat-level3=Bath+Tubs&saleformat=saleformat&site_id=0&RlogId=t6e%2560cpfg%253C%253Dsm%257Eaf%2560qba%252840%253A702-15753cbd4ec-0xfe&dp_store=Basic&rb-discount=0&freeshipping=1&value_pack_info=Value+Pack+is+Gallery+Plus%2C+Listing+Designer%2C+and+Subtitle+packaged+together+for+a+discount.&store=1&n_reserveprice=0&n_finalsaleprice=100&finalsaleprice=%24100.00
EDIT :
here is the response headers :
Content-Encoding → gzip
Content-Length → 2312
Content-Type → text/html;charset=UTF-8
Date → Sat, 22 Oct 2016 15:10:25 GMT
ETag → 6faadcbec2626c16a5eb2715c89aa47f
Last-Modified → Sat, 22 Oct 2016 14:31:15 GMT
Server → Apache-Coyote/1.1
response body:
From collectibles to cars, buy and sell all kinds of items on eBay
Page Not Responding
The eBay page or feature you are attempting to access is not responding.
Please try the options below:
Try to access the feature directly from the eBay Home Page, instead of using a bookmark.
Wait a few minutes and try to access the feature again.
If you have waited ten to fifteen minutes and you still can't access your page:
Check our Announcement Board to see if the feature is currently unavailable.
If what you are looking for is unavailable, you may still be able to access other parts of the site from the eBay Home page
I am using ESP8266-Websocket, aws-sdk-arduino(cleaned branch) and pubsubclient to try to comunicate with aws iot mqtt service using websockets.
My question is about the first connection request. I am using this browser app as reference https://github.com/awslabs/aws-iot-examples and the sign code from aws-sdk-arduino (that works fine calling the aws iot restful api)
My request was this (after connect to the endpoint at 443 port):
GET wss://ENDPOINT.iot.us-west-2.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
host: ENDPOINT.iot.us-west-2.amazonaws.com
Connection: Upgrade
Upgrade: websocket
Origin: file://
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: D2alJOyUkBlR+8yhv2UBLg==
Sec-WebSocket-Protocol: mqtt
but I keep getting
HTTP/1.1 403 Forbidden
content-type: application/json
content-length: 241
date: Fri, 18 Mar 2016 18:34:57 GMT
x-amzn-RequestId: f2edfe83-1bbc-4481-97e0-39ccfc4d1c2f
connection: Keep-Alive
x-amzn-ErrorType: ForbiddenException:
am i missing some request header parameter? is there anyway to get a better feedback from x-amzn-ErrorType: ForbiddenException? am i messing up in the sign process? (even though it works for rest call)
Yeah, I've finally got response status 101 switching protocols \o/
when you are building the request, it must be:
GET /mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
instead of
GET wss://ENDPOINT.iot.us-west-2.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
the js example that I was following was using the full path. When I got the request built by chrome (throught developer tools) the path was full as well. Just after use firebug I got the real request that browser was sending to the server (with short path).
now I can continue to try the solution (mqtt over websockets at esp8266) :-) if it works, I will share the code ;-)
I built a WebSocket server using WebSocket-Node and the client is an Arduino with an Ethernet shield using the library WebsocketClient from krohling.
The first issue I had was that even the example from the WebsocketClient library didn't return a response from the echo.websocket.org server.
Since the Arduino's Serial monitor didn't give me errors, I added a Serial.print on the handshake section of the library's code to debug the error and I got the following:
HTTP/1.1 400 Bad Request
Server: Kaazing Gateway
Date: Tue, 07 May 2013 05:11:21 GMT
Access-Control-Allow-Origin: ArduinoWebSocketClient
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Headers: x-websocket-extensions
Access-Control-Allow-Headers: x-websocket-version
Access-Control-Allow-Headers: x-websocket-protocol
Content-Type: text/html
Content-Length: 63
Connection: Keep-Alive
Then, I tested it with the WebSocket-Node server I created and got the following on the Serial monitor:
HTTP/1.1 400 Bad Request
Connection: close
X-WebSocket-Reject-Reason: Client must provide a value for Sec-WebSocket-Key.
Am I doing something wrong or does the WebsocketClient library need to be updated?
I haven't been lucky to find a better/newer Arduino Websocket client library. Does anyone know about one I could use?
Thanks a lot!
I found the apache xfire has add one head parameter in its post header:
POST /testservice/services/TestService1.1 HTTP/1.1
SOAPAction: "testAPI" Content-Type: text/xml; charset=UTF-8
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; XFire Client +http://xfire.codehaus.org)
Host: 192.168.10.111:9082
Expect: 100-continue
Will this Expect: 100-continue make the roundtrip call between the xfire client and its endpoint server a little bit waste because it will use one more handshake for the origin server to return the "willing to accept request"?
This just my guess.
Vance
I know this is old question but as I was just researching the subject, here is my answer. You don't really need to use "Expect: 100-continue" and it indeed does introduce extra roundtrip. The purpose of this header is to indicate to the server that you want your request to be validated before posting the data. This also means that if it is set, you are committed to waiting (within your own timeout period - not indefinitely!) for server response (either 100 or HTTP failure) before sending your form or data. Although it seems like extra expense, it is meant to improve performance in failure cases, by allowing the server to make you know not to send the data (since the request has failed).
If the header is not set by the client, this means you are not awaiting for 100 code from the server and should send your data in the request body. Here is relevant standard: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html (jump to section 8.2.3).
Hint for .NET 4 users: this header can be disabled using static property "Expect100Continue"
Hint for libcurl users: there was a bug in old version 7.15 when disabling this header wasn't working; fixed in newer versions (more here: http://curl.haxx.se/mail/lib-2006-08/0061.html)