Not sure why I am getting this issue, But My Websocket Connection works on specific ISP while fails on others. I know it sounds absurd but it is happening. My websocket connection works on Two ISP while fails on one. I am using Wildfly Application Server serving the WS Connection and Apache WebServer for proxy forwarding.
Here is the detail of my Request/Response,
General
Request URL:ws://example.com/chat/3
Request Method:GET
Status Code:101 Switching Protocols
Response Headers
Connection:Upgrade
Content-Length:0
Date:Fri, 13 May 2016 13:09:11 GMT
Origin:http://example.com
Sec-WebSocket-Accept:pPjTLv5Dz+/vyjY/SkeMihaXDd0=
Sec-WebSocket-Location:ws://example.com/chat/3
Server:WildFly/9
Upgrade:WebSocket
X-Powered-By:Undertow/1
Request Headers
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:Upgrade
Cookie:mp_c4f10660603c33a8e9307b70e6767539_mixpanel=%7B%22distinct_id%22%3A%20%2215210855b11180-0ffdda567-1821170c-d37aa-15210855b123f2%22%2C%22%24initial_referrer%22%3A%20%22%24direct%22%2C%22%24initial_referring_domain%22%3A%20%22%24direct%22%7D; mf_user=a60cd2cdcfc41836645d949f71ee3127; intercom-id=d1af89ac-9d55-4fef-8a17-3848d8ef0fce; wooTracker=VQf16pMBx4Pu; _ga=GA1.2.544774749.1447732319; JSESSIONID=z4a1hBpQJQz4YCsLivHRRFf8b0dzYzBsT_4PLadB.ip-172-30-0-20; mf_154095de-56ef-4099-9976-f9a298cf0677=8438220eda64d856436d798ca0b9188a|05132367e34aabbf7bcce5b1e8811235b0bd15d4|1463144963483||19|
Host:example.com
Origin:http://example.com
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:94OH1SxHvszgJO6Rg31WGA==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
However, When I tried testing some of the Demo Sites like http://websocket.org/echo.html they are working as expected.
The only difference I found between those connections was header on response from the server Upgrade:websocket whereas my server is returning Upgrade:WebSocket as part of the response. However, I believe that the header are case insensitive and it shouldn't be the issue.
Also, Is it possible to rewrite the Header value for the Response using apache header mod?
Related
I noticed that in the FineUploader server demos (s3demo-thumbnails-cors.php), there is an area that checks if the browser supports preview. It simply checks this post variable: $_POST["isBrowserPreviewCapable"]
The awkward thing here I'd like to ask is, I'm actually using Chrome 40, and I'm absolutely sure that preview is available for my browser. But in the "upload_success" ajax call sent out by FineUploader, it does NOT contain $_POST["isBrowserPreviewCapable"].
Here is a sample dump of my upload success AJAX call. I was wondering if I had missed some sort of configuration for this:
Remote Address:127.0.0.1:80
Request URL:http://localhost/development/code-base/ci/builds/xyz/en/file/api/notify_successful_upload
Request Method:POST
Status Code:200 OK
Request Headers
Accept:application/json
Accept-Encoding:gzip, deflate
Accept-Language:ja,en;q=0.8,en-US;q=0.6,zh;q=0.4,zh-TW;q=0.2,zh-CN;q=0.2,ko;q=0.2
Cache-Control:no-cache
Connection:keep-alive
Content-Length:614
Content-Type:application/x-www-form-urlencoded
Cookie:PHPSESSID=952ciound37e9dkaf5d1hmmc1; __atuvc=10%7C5; CKFinder_Path=Attachments%3A%2F%3A1; logged_in=9db847c22b2bef66cc06091e355a80e6aff83b7d377; abc_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2244ef7cfb140643bdb09df62f0e9c3561%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A9%3A%22127.0.0.1%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A109%3A%22Mozilla%2F5.0+%28Windows+NT+6.1%3B+WOW64%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Chrome%2F40.0.2214.115+Safari%2F537.36%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1424977019%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7Ddc95cd1bb88507af0eb260abe18f380bbd80e1fd; user_locale=en
Host:localhost
Origin:http://localhost
Referer:http://localhost/development/code-base/ci/builds/xyz/en/file
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Data
key:clients/abclient/www/gallery/images/w100/_try_90b313b2-9cea-42f3-8332-e6d13071ded3.png
uuid:c9ed8346-43fb-4116-afe6-18867079524e
name:_try (w100).png
bucket:xyz-production
etag:"b2df53409d64b9e1cb9f1e590d2a4bf6"
file_uuid:c9ed8346-43fb-4116-afe6-18867079524e
file_family_uuid:90b313b2-9cea-42f3-8332-e6d13071ded3
file_storage:s3
file_module:gallery
file_type:images
file_variation:w100
file_name:_try_90b313b2-9cea-42f3-8332-e6d13071ded3.png
file_display_name:_try (w100).png
qqparentuuid:90b313b2-9cea-42f3-8332-e6d13071ded3
qqparentsize:44936
qquuid:c9ed8346-43fb-4116-afe6-18867079524e
Response Headers
Access-Control-Allow-Origin:http://localhost
Connection:Keep-Alive
Content-Length:539
Content-Type:text/html
Date:Thu, 26 Feb 2015 18:57:03 GMT
Keep-Alive:timeout=5, max=94
Server:Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12
Set-Cookie:user_locale=en; expires=Thu, 26-Feb-2015 20:57:03 GMT; Max-Age=7200; path=/
X-Powered-By:PHP/5.5.12
Any help would be greatly appreciated. Thanks!
Cheers,
Thomas
Fine Uploader does not send the POST variable you are speaking of. The S3 demo on http://fineuploader.com/demos includes a line of code that ensures the parameter is sent with the request.
For example, the following option is configured:
uploadSuccess: {
endpoint: "http://s3-demo.fineuploader.com/s3demo-thumbnails-cors.php?success",
params: {
isBrowserPreviewCapable: qq.supportedFeatures.imagePreviews
}
}
What is a common approach in authenticating of user session for websocket connection?
As I understand websocket message contains data only with no headers. Thus authorization cookie is not available to server backend. How should application distinguish messages from different clients?
Which websocket server are you using?
if your webserver and websocketserver are the same, you could send the sessionid via websocket and force-disconnect any client that does not send a valid sessionid in his first message.
if your websocketserver parses the HTTP headers sent in the HTTP upgrade request properly, it may also save any cookie. this is what a request of my firefox (version 35) looks like:
GET /whiteboard HTTP/1.1
Host: *:*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Sec-WebSocket-Version: 13
Origin: *
Sec-WebSocket-Protocol: whiteboard
Sec-WebSocket-Key: iGPS0jjbNiGAYrIyC/YCzw==
Cookie: PHPSESSID=9fli75enklqmv1a30hbdmg1461
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
as you see, the phpsessionid is transmitted fine. check the documentation of your websocketserver if it parses the HTTP headers. remember that cookies will not be sent if the websocket's domain differs from the webserver's domain.
Recently i change to a dedicated server and i start having problems to save large string in a jquery ajax post. in the old server works fine's but in this new server i get an Apache 413 error.
Firebug send this response:
Encabezados de la respuesta
Connection close
Content-Encoding gzip
Content-Length 331
Content-Type text/html; charset=iso-8859-1
Date Mon, 06 Aug 2012 20:53:23 GMT
Server Apache
Vary Accept-Encoding
Encabezados de la petición
Accept */*
Accept-Encoding gzip, deflate
Accept-Language es-MX,es;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Content-Length 1105294
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Cookie SpryMedia_DataTables_table-objetos_crear.php=%7B%22iCreate%22%3A1344285216690%2C%22iStart%22%3A0%2C%22iEnd%22%3A10%2C%22iLength%22%3A10%2C%22sFilter%22%3A%22%22%2C%22sFilterEsc%22%3Atrue%2C%22aaSorting%22%3A%5B%20%5B1%2C%22asc%22%5D%5D%2C%22aaSearchCols%22%3A%5B%20%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%5D%2C%22abVisCols%22%3A%5B%20true%2Ctrue%2Ctrue%2Ctrue%2Ctrue%5D%7D; SpryMedia_DataTables_confs-tabla_index.php=%7B%22iCreate%22%3A1344286395266%2C%22iStart%22%3A0%2C%22iEnd%22%3A8%2C%22iLength%22%3A10%2C%22sFilter%22%3A%22%22%2C%22sFilterEsc%22%3Atrue%2C%22aaSorting%22%3A%5B%20%5B8%2C%22desc%22%5D%2C%5B4%2C%22asc%22%5D%2C%5B0%2C%22asc%22%5D%2C%5B1%2C%22asc%22%5D%2C%5B2%2C%22asc%22%5D%5D%2C%22aaSearchCols%22%3A%5B%20%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%5D%2C%22abVisCols%22%3A%5B%20true%2Ctrue%2Ctrue%2Ctrue%2Ctrue%2Ctrue%2Ctrue%2Ctrue%2Cfalse%2Ctrue%2Cfalse%5D%7D; PHPSESSID=3d8f502be166becd4e504a438eb2b4ae; chkFiltroCol2=; COL=misconfs; ACCION=CONF_EDITAR_CONTENIDO; CONF_ID=279
Host eduweb.mx
Referer http://myserver.com/edit-article.php
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
X-Requested-With XMLHttpRequest
Googling i found the error was in the size of LimitRequestBody, i change it to 64Mb but i still getting this error.
any ideas how to solve this?
It's what worked for me:
in modsecurity.conf file
On my Ubuntu 14.04 the config file is here but this really depends on the system:/etc/modsecurity/modsecurity.conf
change this two commands to this values:
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 13107200
LimitRequestBody is probably not what you want. That's the request body, not the headers which is what it looks like is too long. Try setting the LimitRequestFieldSize, which by default is 8k, to something larger (Note the warning about precedence about this setting).
You may be bumping into an SSL renegotiate buffer overflow situation. Check your Apache log file. The quick fix if this is the case is to use the SSLRenegBufferSize directive to increase your renegotiate buffer. See SSL Renegotiation with Client Certificate causes Server Buffer Overflow
I'm currently trying to connect to a webservice placed on https://xxx.xxx.xx/myapp
It has anonymous access and SSL enabled for testing purposes atm.
While trying to connect from the 3G network, i get Status 403: Access denied. You do not have permission to view this directory or page using the credentials that you supplied.
I get these headers while trying to connect to the webservice locally:
Headers
Request URL:https://xxx.xxx.xx/myapp
Request Method:GET
Status Code:200 OK
Request Headers
GET /myapp/ HTTP/1.1
Host: xxx.xxx.xxx
Connection: keep-alive
Authorization: Basic amViZTAyOlE3ZSVNNHNB
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: sv-SE,sv;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response Headers
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 16 Feb 2012 12:26:13 GMT
Content-Length: 622
But when accessing outside the local area, we get the big ol 403. Which in turn wants credentials to grant the user access to the webservice.
However, i've tried using the ASIHTTPRequest library without success, and that project has been abandoned. And they suggest going back to NSURLConnection.
And i have no clue where to start, not even which direction to take.
-connection:(connection *)connection didRecieveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
The above delegate method of NSURLConnection doesnt even trigger. So i have no idea what so ever how to authenticate myself.
All i get is the parsed results of the xml elements of the 403-page.
I needs dem seriouz helps! plx.
This was all just a major f-up.
The site had ssl required and enabled, and setting ssl required for the virtual directories does some kind of superduper meta-blocking.
So, by disabling ssl required for the virtual directories, it runs over ssl and is not blocking 3G access..
I have following problem with site http://huti.ru. When trying to add any of its pages in http://webmaster.yandex.ru/addurl.xml (Yandex - russian search engine) wrote "The server returns a status code http 405 (expected code 200)." What can caouse such different behevior for brawusers and yandex crawler? (Google indexes like normal)
Enviroment: tomcat, java 6
Your server does not allow HEAD requests. Seems that the robot first tries a HEAD before the actual GET.
As
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
states: HEAD should be identical to GET, except that it does never return a message body, but only the response headers for a particular request.
Note: I did a simple
HEAD / HTTP/1.0
request. Same with HTTP/1.1 + Host: huti.ru.
Check your server logs for the actual content of the response to the Yandex request.
HTTP 405 is Method Not Allowed, and is usually returned if the user agent has used an HTTP verb not supported for the particular resource.
For example, using Fiddler, I issued several requests to http://huti.ru, and I got 200 response for the HEAD, GET, and POST, but I got 405 for the TRACE. It's conceivable that Yandex issues either TRACE or OPTIONS, before making a request for the actual page as a form of a ping to determine if the page exists.
Note: #smilingthax mentioned that your server returns 405 on HEAD. However, issuing the following request from Fiddler worked for me:
HEAD http://huti.ru/ HTTP/1.1
Host: huti.ru
Proxy-Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.23 Safari/534.10
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Thus, your problem might be specific to HEAD requests with particular headers.
I think that 405 means that the page has already been indexed.