I have a SignalR application that has both Web and .NET clients. The website uses windows authentication:
<authentication mode="Windows" />
<authorization>
<deny users="?" />
</authorization>
It works perfectly from the web client, and the .NET client if I create the credentials manually:
hubConnection.Credentials = new NetworkCredential(username, password);
but I have problems if I use CredentialCache.DefaultCredentials. The HubConnection.Start() succeeds, but a later call to hubProxy.Invoke() fails with an authentication error:
HttpClientException
StatusCode: 401, ReasonPhrase: 'Unauthorized', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
Server: Microsoft-IIS/8.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Tue, 09 Jun 2015 09:07:11 GMT
Content-Length: 1293
Content-Type: text/html
}
The strange thing is that the .NET client receives requests that were registered with the hubProxy.On<>() method, even though it can't send requests!
Edit
So, here is a little more information.
As well as working when the credentials are supplied as a NetworkCredential object, it also appears to work when running in a remote session on our Window 2012 server. Here is what the failed log looks like:
10:28:32.9467758 - null - ChangeState(Disconnected, Connecting)
10:28:33.4358247 - 28f8fa9a-cdb9-4b55-8442-343bdbc6bd11 - SSE: GET https://server/signalr/connect?clientProtocol=1.4&transport=serverSentEvents&connectionData=[{"Name":"NotificationHub"}]&connectionToken=kgusKft%2FzqjiJ%2BlIJL8G9CRmNlDNP5SHSNrFHSPEMkKR1xJNwCa6bMvX%2FoFcxVQzeZ22%2B8pUUDzWMHnpDZEdtNSItYxx4qoH17yDKG20vRnCCM5EYqIi%2BANJSwPwyp8gtgquQ40NSWK%2B4xh7wj8g%3D%3D
10:28:33.4538265 - 28f8fa9a-cdb9-4b55-8442-343bdbc6bd11 - SSE: OnMessage(Data: initialized)
10:28:33.4538265 - 28f8fa9a-cdb9-4b55-8442-343bdbc6bd11 - SSE: OnMessage(Data: {"C":"d-D46072F5-B,5|y,0|T,0|z,1","S":1,"M":[]})
10:28:33.5108322 - 28f8fa9a-cdb9-4b55-8442-343bdbc6bd11 - SSE: OnMessage(Data: {"C":"d-D46072F5- B,5|y,0|T,0|z,2|V,0","G":"0Va/0XgwDTaQJuNkmh+foUAw65Q/VPLZi0zjJjns6qoqwTlKzNqna6IlVZlLZmihC2in5/fr+jzG7G5SNoDbRwDvLb31tD6GiLRv3OqYVjIY6uKpjRgyel86eBlQBuXGpeQcGDONymjnpsSF0GyGZrnEaKDa3Ph84x67Am6PU=","M":[]})
10:28:33.5178329 - 28f8fa9a-cdb9-4b55-8442-343bdbc6bd11 - ChangeState(Connecting, Connected)
10:28:41.6636474 - 28f8fa9a-cdb9-4b55-8442-343bdbc6bd11 - SSE: OnMessage(Data: {})
10:28:51.0955881 - 28f8fa9a-cdb9-4b55-8442-343bdbc6bd11 - Exception thrown by Task: System.AggregateException: One or more errors occurred. ---> Microsoft.AspNet.SignalR.Client.HttpClientException: StatusCode: 401, ReasonPhrase: 'Unauthorized', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
Server: Microsoft-IIS/8.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Thu, 11 Jun 2015 10:28:51 GMT
Content-Length: 1293
Content-Type: text/html
}
And here is the log from a successful attempt:
08:48:10.4054328 - null - ChangeState(Disconnected, Connecting)
08:48:11.6989325 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: GET https://server/signalr/connect?clientProtocol=1.4&transport=serverSentEvents&connectionData=[{"Name":"NotificationHub"}]&connectionToken=PY5qkPBIdZJ2%2FHIpDoMz7%2BM6njFH7Ky%2BfAa4NPf9TuZc0Rptpo%2BZfhQddF3rONtbmVB6N3fCjnigAJa5e7TBAYqADqwzSwTsQBL8SKE66Ffp9U4tHgGp%2B22e1ml6voPYEbIsMtaP60oTI0dn6AAEYFtTmjo%2FFTwQmWXdUhS4%3D
08:48:12.0891098 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: initialized)
08:48:12.1051173 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: {"C":"d-AE2CE5E6-B,8|Bw,0|Bl,0|Bx,1","S":1,"M":[]})
08:48:12.6012242 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: {"C":"d-AE2CE5E6-B,8|Bw,0|Bl,0|Bx,2|Bn,0","G":"9uGkt7Ji5H7e9BqgYRvssYqHcUqaB2f/QZWW3HDkaO6s+uDE1+49KkzNWmjyP4RSkd7GRhaEa3uQ68J0v488gxGjqJMyeHrui21kFDLLl4AFITvFrTJMa92pSAUkjq0ZF4qVfG51UDJ6TT2O9p6ZmOe7HVtZXMLWwyASVq6VFV4=","M":[]})
08:48:12.6282349 - 62345d8c-fdae-4fec-baa1-19125f908120 - ChangeState(Connecting, Connected)
08:48:18.9582313 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: {})
08:48:28.9796826 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: {})
08:48:34.5974895 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: {"C":"d-AE2CE5E6-B,8|Bw,1|Bl,0|Bx,2|Bn,0","M":[{"H":"NotificationHub","M":"Hello","A":[]}]})
08:48:34.5994973 - 62345d8c-fdae-4fec-baa1-19125f908120 - OnMessage({"I":"0"})
08:48:38.9895450 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: {})
08:48:49.0992213 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: {})
08:48:59.1190704 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: {})
The point at which the error occurs is the call to Hello:
08:48:34.5974895 - 62345d8c-fdae-4fec-baa1-19125f908120 - SSE: OnMessage(Data: {"C":"d-AE2CE5E6-B,8|Bw,1|Bl,0|Bx,2|Bn,0","M":[{"H":"NotificationHub","M":"Hello","A":[]}]})
Edit 2
A bit more information - I only have the problem when using https. I now have my windows clients connecting over http and everything is fine. I would like to move back to https, but fortunately it is not essential for this project.
Related
I've got a SPA web app that uses gRPC web and envoy to proxy back to a server that speaks gRPC. This all works great, no problems.
I'm trying to make this secure using HTTPS/TLS and just keep running into issues and can't make it work.
Our setup is this:
Web Client SPA app (accessed from web node.js server also running on the lahinch server. URL is https://lahinch.mycorp.com ). Web app connects to the envoy proxy using this address "https://coxos.mycorp.COM:8090"
\
Envoy Proxy (coxos - 172.16.0.116) - listens on port 8090 and proxies to port 50251
\
\
Backend gRPC server (lahinch - 172.16.0.109) - listens on port 50251
From reading the envoy docs, the web client is downstream and the backend server is upstream.
Here is my envoy.yaml file
admin:
access_log_path: /tmp/admin_access.log
address:
socket_address:
address: 0.0.0.0
port_value: 9901
static_resources:
listeners:
- name: listener_0
address:
socket_address:
address: 0.0.0.0
port_value: 8090
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
'#type': >-
type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
access_log:
- name: envoy.access_loggers.file
typed_config:
'#type': >-
type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
path: /dev/stdout
- name: envoy.access_loggers.http_grpc
typed_config:
'#type': >-
type.googleapis.com/envoy.extensions.access_loggers.grpc.v3.HttpGrpcAccessLogConfig
common_config:
log_name: envoygrpclog
grpc_service:
envoy_grpc:
cluster_name: controlweb_backendservice
transport_api_version: V3
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains:
- '*'
routes:
- match:
prefix: /
route:
cluster: controlweb_backendservice
hash_policy:
- header:
header_name: x-session-hash
max_stream_duration:
grpc_timeout_header_max: 300s
cors:
allow_origin_string_match:
- safe_regex:
google_re2: {}
regex: .*
allow_methods: 'GET, PUT, DELETE, POST, OPTIONS'
allow_headers: >-
keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,grpc-status-details-bin,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web,grpc-timeout,access-token,x-session-hash
expose_headers: >-
grpc-status-details-bin,grpc-status,grpc-message,access-token
max_age: '1728000'
http_filters:
- name: envoy.filters.http.grpc_web
typed_config:
'#type': >-
type.googleapis.com/envoy.extensions.filters.http.grpc_web.v3.GrpcWeb
- name: envoy.filters.http.cors
typed_config:
'#type': >-
type.googleapis.com/envoy.extensions.filters.http.cors.v3.Cors
- name: envoy.filters.http.router
typed_config:
'#type': >-
type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
transport_socket:
name: envoy.transport_sockets.tls
typed_config:
# https://www.envoyproxy.io/docs/envoy/v1.17.0/api-v3/extensions/transport_sockets/tls/v3/tls.proto#extensions-transport-sockets-tls-v3-downstreamtlscontext
"#type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
common_tls_context:
tls_certificates:
- certificate_chain:
# Certificate must be PEM-encoded
filename: /etc/lahinch.pem
private_key:
filename: /etc/lahinch.key.pem
validation_context:
trusted_ca:
filename: /etc/ssl/certs/ZZZ-CA256.pem
clusters:
- name: controlweb_backendservice
type: LOGICAL_DNS
connect_timeout: 0.25s
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: cluster_controlweb_backendservice
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: lahinch.mycorp.com
port_value: 50251
http2_protocol_options: {}
transport_socket:
name: envoy.transport_sockets.tls
typed_config:
'#type': >-
type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
common_tls_context:
tls_certificates:
- certificate_chain:
filename: /etc/lahinch.pem
private_key:
filename: /etc/lahinch.key.pem
validation_context:
trusted_ca:
filename: /etc/ssl/certs/ZZZ-CA256.pem
Using this, I'm getting the following in the envoy log when I try and run my web app:
[2021-04-09 22:08:33.939][17][debug][conn_handler] [source/server/connection_handler_impl.cc:501] [C2] new connection
[2021-04-09 22:08:33.945][17][debug][http] [source/common/http/conn_manager_impl.cc:254] [C2] new stream
[2021-04-09 22:08:33.945][17][debug][http] [source/common/http/conn_manager_impl.cc:886] [C2][S3055347406573314092] request headers complete (end_stream=false):
':authority', 'coxos.mycorp.com:8090'
':path', '/WanderAuth.HostService/LogIn'
':method', 'POST'
'connection', 'keep-alive'
'content-length', '124'
'accept', 'application/grpc-web-text'
'x-user-agent', 'grpc-web-javascript/0.1'
'access-token', ''
'x-grpc-web', '1'
'user-agent', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36 Edg/89.0.774.68'
'grpc-timeout', '90000m'
'content-type', 'application/grpc-web-text'
'origin', 'https://lahinch.mycorp.com'
'sec-fetch-site', 'same-site'
'sec-fetch-mode', 'cors'
'sec-fetch-dest', 'empty'
'referer', 'https://lahinch.mycorp.com/'
'accept-encoding', 'gzip, deflate, br'
'accept-language', 'en-US,en;q=0.9'
[2021-04-09 22:08:33.946][17][debug][router] [source/common/router/router.cc:425] [C2][S3055347406573314092] cluster 'controlweb_backendservice' match for URL '/WanderAuth.HostService/LogIn'
[2021-04-09 22:08:33.946][17][debug][router] [source/common/router/router.cc:582] [C2][S3055347406573314092] router decoding headers:
':authority', 'coxos.mycorp.com:8090'
':path', '/WanderAuth.HostService/LogIn'
':method', 'POST'
':scheme', 'https'
'accept', 'application/grpc-web-text'
'x-user-agent', 'grpc-web-javascript/0.1'
'access-token', ''
'x-grpc-web', '1'
'user-agent', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36 Edg/89.0.774.68'
'grpc-timeout', '90000m'
'content-type', 'application/grpc'
'origin', 'https://lahinch.mycorp.com'
'sec-fetch-site', 'same-site'
'sec-fetch-mode', 'cors'
'sec-fetch-dest', 'empty'
'referer', 'https://lahinch.mycorp.com/'
'accept-encoding', 'gzip, deflate, br'
'accept-language', 'en-US,en;q=0.9'
'x-forwarded-proto', 'https'
'x-request-id', 'a4a041ab-dc29-4ed7-a342-90ac03b3be3c'
'te', 'trailers'
'grpc-accept-encoding', 'identity'
'x-envoy-expected-rq-timeout-ms', '15000'
[2021-04-09 22:08:33.946][17][debug][pool] [source/common/http/conn_pool_base.cc:79] queueing stream due to no available connections
[2021-04-09 22:08:33.946][17][debug][pool] [source/common/conn_pool/conn_pool_base.cc:106] creating a new connection
[2021-04-09 22:08:33.946][17][debug][client] [source/common/http/codec_client.cc:41] [C3] connecting
[2021-04-09 22:08:33.946][17][debug][connection] [source/common/network/connection_impl.cc:860] [C3] connecting to 172.16.0.109:50251
[2021-04-09 22:08:33.946][17][debug][connection] [source/common/network/connection_impl.cc:876] [C3] connection in progress
[2021-04-09 22:08:33.946][17][debug][http2] [source/common/http/http2/codec_impl.cc:1184] [C3] updating connection-level initial window size to 268435456
[2021-04-09 22:08:33.946][17][debug][http] [source/common/http/filter_manager.cc:755] [C2][S3055347406573314092] request end stream
[2021-04-09 22:08:33.947][17][debug][connection] [source/common/network/connection_impl.cc:666] [C3] connected
[2021-04-09 22:08:33.947][17][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:224] [C3] TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2021-04-09 22:08:33.948][17][debug][connection] [source/common/network/connection_impl.cc:241] [C3] closing socket: 0
[2021-04-09 22:08:33.948][17][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:224] [C3] TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2021-04-09 22:08:33.948][17][debug][client] [source/common/http/codec_client.cc:99] [C3] disconnect. resetting 0 pending requests
[2021-04-09 22:08:33.948][17][debug][pool] [source/common/conn_pool/conn_pool_base.cc:343] [C3] client disconnected, failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2021-04-09 22:08:33.948][17][debug][router] [source/common/router/router.cc:1026] [C2][S3055347406573314092] upstream reset: reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2021-04-09 22:08:33.948][17][debug][http] [source/common/http/filter_manager.cc:839] [C2][S3055347406573314092] Sending local reply with details upstream_reset_before_response_started{connection failure,TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER}
[2021-04-09 22:08:33.948][17][debug][http] [source/common/http/conn_manager_impl.cc:1484] [C2][S3055347406573314092] encoding headers via codec (end_stream=false):
':status', '503'
'content-length', '190'
'content-type', 'application/grpc-web-text+proto'
'access-control-allow-origin', 'https://lahinch.mycorp.com'
'access-control-expose-headers', 'grpc-status-details-bin,grpc-status,grpc-message,access-token'
'date', 'Fri, 09 Apr 2021 22:08:33 GMT'
'server', 'envoy'
[2021-04-09 22:08:36.139][9][debug][upstream] [source/common/upstream/logical_dns_cluster.cc:101] starting async DNS resolution for lahinch.mycorp.com
[2021-04-09 22:08:36.139][9][debug][main] [source/server/server.cc:199] flushing stats
[2021-04-09 22:08:36.141][9][debug][upstream] [source/common/upstream/logical_dns_cluster.cc:109] async DNS resolution complete for lahinch.mycorp.com
[2021-04-09 22:08:36.141][9][debug][upstream] [source/common/upstream/logical_dns_cluster.cc:155] DNS refresh rate reset for lahinch.mycorp.com, refresh rate 5000 ms
So the error appears to be this: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
I've looked up this error and it appears to be be related to security and certificates. But I haven't been able to find a good answer as to what I'm doing wrong.
When it comes to the required certs, should the certs be the same that is used by client(downstream), the proxy or the backend(upstream server) or both? I've tried using different certs for the different servers and the same certs for the servers and I still get the same error.
I am trying to connect to thingsboard server using thingsboard IoT gateway. I have followed all steps given in the below link : https://thingsboard.io/docs/iot-gateway/install/source-installation/
When running tb-gateway with command : python3 ./thingsboard_gateway/tb_gateway.py
I am getting below error message :
INFO - [mqtt_connector.py] - mqtt_connector - 157 - Number of rejected mapping handlers: 0"
INFO - [mqtt_connector.py] - mqtt_connector - 153 - Number of accepted serverSideRpc handlers: 2"
INFO - [mqtt_connector.py] - mqtt_connector - 157 - Number of rejected serverSideRpc handlers: 0"
INFO - [mqtt_connector.py] - mqtt_connector - 153 - Number of accepted connectRequests handlers: 2"
INFO - [mqtt_connector.py] - mqtt_connector - 157 - Number of rejected connectRequests handlers: 0"
INFO - [mqtt_connector.py] - mqtt_connector - 153 - Number of accepted disconnectRequests handlers: 2"
INFO - [mqtt_connector.py] - mqtt_connector - 157 - Number of rejected disconnectRequests handlers: 0"
ERROR - [mqtt_connector.py] - mqtt_connector - 130 - 'attributeRequests' section missing from configuration"
INFO - [mqtt_connector.py] - mqtt_connector - 153 - Number of accepted attributeUpdates handlers: 1"
INFO - [mqtt_connector.py] - mqtt_connector - 157 - Number of rejected attributeUpdates handlers: 0"
INFO - [tb_gateway_service.py] - tb_gateway_service - 135 - Gateway started."
ERROR - [tb_client.py] - tb_client - 132 - [WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"
Traceback (most recent call last):
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python39\lib\site-packages\thingsboard_gateway-2.5.4-py3.9.egg\thingsboard_gateway\gateway\tb_client.py", line 127, in run
self.client.connect(keepalive=keep_alive,
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python39\lib\site-packages\thingsboard_gateway-2.5.4-py3.9.egg\thingsboard_gateway\tb_client\tb_device_mqtt.py", line 167, in connect
self._client.connect(self.__host, self.__port, keepalive=keepalive)
I have done below changes in the respective files :
mqtt.json :
"broker": {
"name":"Default Local Broker",
"host":"IP Address",
"port":1883,
"clientId": "ThingsBoard_gateway",
"security": {
"type": "basic",
"username": "**********",
"password": "***********"
}
}
tb_gateway.yaml :
host: "IP Address"
port: 1883
remoteShell: false
remoteConfiguration: false
security:
accessToken: ********************
qos: 1
storage:
type: memory
read_records_count: 100
max_records_count: 100000
connectors:
-
name: MQTT Broker Connector
type: mqtt
configuration: mqtt.json
Appreciate your help. Thanks in advance.
Do you have any server ? I gonna explain my method. for example I have a TCP server. But I can not directly connect with my TCP server as a client to thingsboard. But everyone can connect to thingsboard as a mqtt client. Just one role, you need to know your device access token in thingsboard. if you know access token you can connect to thingsboard as a client by using mqtt://demo.thingsboard.io, { username: "ACCESS_TOKEN" } url and v1/devices/me/telemetry topic. example js code that running with node.js. var client = mqtt.connect('mqtt://demo.thingsboard.io' + { username: "AccessToken" }); and to publish client.publish('v1/devices/me/telemetry', JSON.stringify(data));
I came across a very interesting situation. I am running a apache server inside a Docker container, running a mediawiki installation.
When I run curl localhost:8081 -v, I get a valid response. Also visiting the website in the browser redirects me to the main page as expected:
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8081 (#0)
> GET / HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Sun, 01 Nov 2020 05:18:33 GMT
< Server: Apache/2.4.38 (Debian)
< X-Powered-By: PHP/7.3.24
< X-Content-Type-Options: nosniff
< Vary: Accept-Encoding,Cookie
< Expires: Sun, 01 Nov 2020 05:18:33 GMT
< Cache-Control: private, must-revalidate, max-age=0
< Last-Modified: Sun, 01 Nov 2020 05:18:33 GMT
< Location: http://wiki.10.0.0.20.xip.io/wiki/Main_Page
< Connection: close
< Content-Encoding: none
< Content-Length: 0
< X-Request-Id: 76816afe025ea1c1ced4d30d
< Content-Type: text/html; charset=utf-8
<
* Closing connection 0
When on the other hand I make the request through the nginx ingress, I get the following:
* Trying 10.0.0.20...
* TCP_NODELAY set
* Connected to wiki.10.0.0.20.xip.io (10.0.0.20) port 80 (#0)
> GET / HTTP/1.1
> Host: wiki.10.0.0.20.xip.io
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.19.1
< Date: Sun, 01 Nov 2020 05:25:49 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< X-Powered-By: PHP/7.3.24
< X-Content-Type-Options: nosniff
< Vary: Accept-Encoding,Cookie
< Expires: Sun, 01 Nov 2020 05:25:49 GMT
< Cache-Control: private, must-revalidate, max-age=0
< Last-Modified: Sun, 01 Nov 2020 05:25:49 GMT
< Location: http://wiki.10.0.0.20.xip.io/wiki/Main_Page
< Content-Encoding: none
< X-Request-Id: d6457fbb4f7cc3d0003206eb
<
* Connection #0 to host wiki.10.0.0.20.xip.io left intact
* Closing connection 0
As you can see, the Location header is the same in both responses. The only difference in my eyes is the Connection: keep-alive header which is set to close by Apache. Is this forbidden for 301 results?
When I try to open the Page in Chrome/Safari, the pod server works correctly, but the ingress shows the ERR_EMPTY_RESPONSE error message without any further indication. Furthermore, passing any query param to the url, like ?a, shows the start page correctly. This is most likely because any invalid URL is caught by mediawiki and redirected to the start page.
My ingress config is as follows:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
rules:
- host: wiki.10.0.0.20.xip.io
http:
paths:
- path: /(.*)
pathType: Prefix
backend:
service:
name: mediawiki
port:
number: 80
The kubernetes environment has been created via minikube. I am using the local NAT network adapter from VirtualBox. But also with a bridged network it is the same from another machine. You can see that the connection is established as I see the 301. Also it routes to mediawiki/PHP, but then the response becomes invalid on the way.
I deployed the service as follows:
apiVersion: v1
kind: Service
metadata:
name: mediawiki
spec:
type: NodePort
selector:
app: mediawiki
ports:
- protocol: TCP
port: 80
nodePort: 30090
And the deployment looks like this:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mediawiki
labels:
app: mediawiki
spec:
replicas: 1
selector:
matchLabels:
app: mediawiki
template:
metadata:
labels:
app: mediawiki
spec:
containers:
- name: mediawiki
image: mediawiki
ports:
- containerPort: 80
volumeMounts:
- name: localsettings
mountPath: "/var/www/html/LocalSettings.php"
readOnly: true
subPath: LocalSettings.php
- name: logo
mountPath: "/var/www/html/resources/assets/wiki.png"
readOnly: true
subPath: logo.png
volumes:
- name: localsettings
configMap:
name: localsettings
- name: logo
configMap:
name: logo
Sorry to bother with something that should be easy.
I have this HTTP GET request:
GET /ip HTTP/1.1
Host: httpbin.org
Connection: close
Accept: */*
User-Agent: Mozilla/4.0 (compatible; esp8266 Lua; Windows NT 5.1)
When I send this request via my ESP8266 it returns a 404 error:
HTTP/1.1 404 Not Found
Date: Fri, 04 Sep 2015 16:34:46 GMT
Server: Apache
Content-Length: 1363
X-Frame-Options: deny
Connection: close
Content-Type: text/html
But when I (and you) go to http://httpbin.org/ip it works perfectly!
What is wrong?
DETAILS
I construct my request in Lua:
conn:on("connection", function(conn, payload)
print('\nConnected')
req = "GET /ip"
.." HTTP/1.1\r\n"
.."Host: httpbin.org\r\n"
.."Connection: close\r\n"
.."Accept: */*\r\n"
.."User-Agent: Mozilla/4.0 (compatible; esp8266 Lua; Windows NT 5.1)\r\n"
.."\r\n"
print(req)
conn:send(req)
end)
And if I use another host (given is this example) it works:
conn:on("connection", function(conn, payload)
print('\nConnected')
conn:send("GET /esp8266/test.php?"
.."T="..(tmr.now()-Tstart)
.."&heap="..node.heap()
.." HTTP/1.1\r\n"
.."Host: benlo.com\r\n"
.."Connection: close\r\n"
.."Accept: */*\r\n"
.."User-Agent: Mozilla/4.0 (compatible; esp8266 Lua; Windows NT 5.1)\r\n"
.."\r\n")
end)
Are you actually connecting to httpbin.org ? Or somewhere else?
I just tried issuing your request by typing it into telnet, and it worked for me. But the server responding was nginx, whereas your example shows apache.
$ telnet httpbin.org 80
Trying 54.175.219.8...
Connected to httpbin.org.
Escape character is '^]'.
GET /ip HTTP/1.1
Host: httpbin.org
Connection: close
Accept: */*
User-Agent: Mozilla/4.0 (compatible; esp8266 Lua; Windows NT 5.1)
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 07 Oct 2015 06:08:40 GMT
Content-Type: application/json
Content-Length: 32
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
{
"origin": "124.149.55.34"
}
Connection closed by foreign host.
When I try another request with some other URI to force a 404 response, I see this:
HTTP/1.1 404 NOT FOUND
Server: nginx
Date: Wed, 07 Oct 2015 06:12:21 GMT
Content-Type: text/html
Content-Length: 233
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Which again is nothing like the response you said you got from httpbin.org.
http.get("http://httpbin.org/ip", nil, function(code, data)
if (code < 0) then
print("HTTP request failed")
else
print(code, data)
end
end)
http.post('http://httpbin.org/post',
'Content-Type: application/json\r\n',
'{"hello":"world"}',
function(code, data)
if (code < 0) then
print("HTTP request failed")
else
print(code, data)
end
end)
see the reference here.
It's your request line the server doesn't like.
This will do the job:
GET http://httpbin.org/ip HTTP/1.1
Host: httpbin.org
I'm using phpari with Asterisk 13 and trying to record a bridge (mixing type).
In my code:
$this->phpariObject->bridges()->bridge_start_recording($bridgeID, "debug", "wav");
It returns:
array(4) {
["name"]=>
string(5) "debug"
["format"]=>
string(3) "wav"
["state"]=>
string(6) "queued"
["target_uri"]=>
string(15) "bridge:5:1:503"
}
When and I stop and save with
$this->phpariObject->recordings()->recordings_live_stop_n_store("debug");
It returns FALSE.
I debug with
curl -v -u xxxx:xxxx -X POST "http://localhost:8088/ari/recordings/live/debug/stop"
Result:
* About to connect() to localhost port 8088 (#0)
* Trying ::1... Connection refused
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8088 (#0)
* Server auth using Basic with user 'xxxxx'
> POST /ari/recordings/live/debug/stop HTTP/1.1
> Authorization: Basic xxxxxxx
> User-Agent: curl/7.19.7 (xxxxx) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: localhost:8088
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Server: Asterisk/13.2.0
< Date: Thu, 19 Feb 2015 11:58:18 GMT
< Cache-Control: no-cache, no-store
< Content-type: application/json
< Content-Length: 38
<
{
"message": "Recording not found"
* Connection #0 to host localhost left intact
* Closing connection #0
}
Asterisk CLI verbose 5 trace: http://pastebin.com/QZXnpXVA
So, I've solved the problem.
It was a simple write permission problem.
Asterisk user couldn't write on /var/spool/asterisk/recording because it was owned by root.
Changing the ownership to the asterisk user solved it.
I detected this problem by looking at the Asterisk CLI trace again:
-- x=0, open writing: /var/spool/asterisk/recording/debug format: sln, (nil)
This (nil) indicates that the file could not be written, so I checked the folder and saw where the problem was.