Intro
I'm sending POST request to server which responses with chunked messages.
So I'm trying to make writecallback being called on each received chunked http message.
Code
#include <iostream>
#include <string>
#include <curl/curl.h>
using namespace std;
size_t write_callback(char *d, size_t n, size_t l, void *userp)
{
cerr << ""--- Called once" << endl;
return n*l;
}
string xml_msg()
{
return "<<some request data>>";
}
curl_slist* get_header(size_t content_length)
{
auto list = curl_slist_append(nullptr, "<<protocol version>>");
list = curl_slist_append(list, "Content-Type: text/xml");
list = curl_slist_append(list, "Content-Length: " + content_length);
return list;
}
void main()
{
auto xml = xml_msg();
curl_global_init(CURL_GLOBAL_ALL);
auto curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL, "<<server url>>");
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, write_callback);
curl_easy_setopt(curl, CURLOPT_WRITEDATA, nullptr);
curl_easy_setopt(curl, CURLOPT_USERAGENT, "Mozilla/4.0 (compatible; MSIE 6.0)");
curl_easy_setopt(curl, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
curl_easy_setopt(curl, CURLOPT_USERPWD, "<<user credentials>>");
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, get_header(xml.size()));
curl_easy_setopt(curl, CURLOPT_POST, 1);
curl_easy_setopt(curl, CURLOPT_POSTFIELDS, xml.data());
curl_easy_setopt(curl, CURLOPT_HTTP_CONTENT_DECODING, 0L);
curl_easy_perform(curl);
curl_easy_cleanup(curl);
curl_global_cleanup();
}
Verbose log
* STATE: INIT => CONNECT handle 0x15c4de0; line 1422 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x15c4de0; line 1458 (connection #0)
* Trying xxx.xxx.xxx.xxx...
* TCP_NODELAY set
* STATE: WAITRESOLVE => WAITCONNECT handle 0x15c4de0; line 1539 (connection #0)
* Connected to <<host>> (xxx.xxx.xxx.xxx) port 80 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x15c4de0; line 1591 (connection #0)
* Marked for [keep alive]: HTTP default
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x15c4de0; line 1605 (connection #0)
* STATE: PROTOCONNECT => DO handle 0x15c4de0; line 1626 (connection #0)
* Server auth using Basic with user '<<credentials>>'
> POST <<URL>>
Host: <<host>>
Authorization: Basic <<base64 credentials>>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0)
Accept: */*
Content-Type: text/xml
Content-Length: 204
* upload completely sent off: 204 out of 204 bytes
* STATE: DO => DO_DONE handle 0x15c4de0; line 1688 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x15c4de0; line 1813 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x15c4de0; line 1823 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Date: Tue, 08 May 2018 12:29:49 GMT
* Server is not blacklisted
< Server: <<server>>
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Content-Language: en-US
< Cache-Control: no-cache, no-store
< Pragma: no-cache
< Content-Type: application/xml;charset=UTF-8
< Set-Cookie: <<cookie>>
< Transfer-Encoding: chunked
<
--- Called once
* STATE: PERFORM => DONE handle 0x15c4de0; line 1992 (connection #0)
* multi_done
* Connection #0 to <<server>> left intact
Problem
Writecallback has been called when connection had been closed by server due to timeout with FIN tcp packet instead of moment when chunked http response has been received.
It is about 30 secs interval between this events.
Question
What am I doing wrong?
Update 1
Server returns a tcp segment with PUSH flag and http message with chunked transfer encoding containing XML. Message ends with CLRF. Meanwhile Win API socket does not allow to read it and select() returns 0, which means that there is nothing to read/write on this socket.
After 30 secs delay before closing connection due to heartbeat timeout (that is internal implementation of the server), server sends finalizing http message with chunked transfer encoding, which contains 0 and CLRF. After that message select() displays new socket state and libcurl calls write callback with returning chunked message content.
That is what I see after debuging libcurl. I need to find out the way to get chunked http message returned by libcurl once it is received, not after getting final http message.
Ok, I was able to find out that the problem is with Win Api sockets. On linux builds libcurl calls writecallback right after receiving chuncked message. I'm not sure how to fix that issue with Win builds, but at least I found rootcause of problem.
Related
I have a Java client, that is making a POST call to the v1/graphql endpoint of a Hasura server (v1.3.3)
I'm making the HTTP call using the Square okhttp3 library (v4.9.1). The data transfer is happening over HTTP1.1, using chunked transfer-encoding.
The client is failing with the following error:
Caused by: java.net.ProtocolException: unexpected end of stream
at okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.read(Http1ExchangeCodec.kt:415) ~[okhttp-4.9.1.jar:?]
at okhttp3.internal.connection.Exchange$ResponseBodySource.read(Exchange.kt:276) ~[okhttp-4.9.1.jar:?]
at okio.RealBufferedSource.read(RealBufferedSource.kt:189) ~[okio-jvm-2.8.0.jar:?]
at okio.RealBufferedSource.exhausted(RealBufferedSource.kt:197) ~[okio-jvm-2.8.0.jar:?]
at okio.InflaterSource.refill(InflaterSource.kt:112) ~[okio-jvm-2.8.0.jar:?]
at okio.InflaterSource.readOrInflate(InflaterSource.kt:76) ~[okio-jvm-2.8.0.jar:?]
at okio.InflaterSource.read(InflaterSource.kt:49) ~[okio-jvm-2.8.0.jar:?]
at okio.GzipSource.read(GzipSource.kt:69) ~[okio-jvm-2.8.0.jar:?]
at okio.Buffer.writeAll(Buffer.kt:1642) ~[okio-jvm-2.8.0.jar:?]
at okio.RealBufferedSource.readString(RealBufferedSource.kt:95) ~[okio-jvm-2.8.0.jar:?]
at okhttp3.ResponseBody.string(ResponseBody.kt:187) ~[okhttp-4.9.1.jar:?]
Request Headers:
INFO: Content-Type: application/json; charset=utf-8
INFO: Content-Length: 1928
INFO: Host: localhost:10191
INFO: Connection: Keep-Alive
INFO: Accept-Encoding: gzip
INFO: User-Agent: okhttp/4.9.1
Response headers:
INFO: Transfer-Encoding: chunked
INFO: Date: Tue, 27 Apr 2021 12:06:39 GMT
INFO: Server: Warp/3.3.10
INFO: x-request-id: d019408e-e2e3-4583-bcd6-050d4a496b11
INFO: Content-Type: application/json; charset=utf-8
INFO: Content-Encoding: gzip
This is the client code used for the making the POST call:
private static final MediaType MEDIA_TYPE_JSON = MediaType.parse("application/json; charset=utf-8");
private static OkHttpClient okHttpClient = new OkHttpClient.Builder()
.connectTimeout(30, TimeUnit.SECONDS)
.writeTimeout(5, TimeUnit.MINUTES)
.readTimeout(5, TimeUnit.MINUTES)
.addNetworkInterceptor(loggingInterceptor)
.build();
public GenericHttpResponse httpPost(String url, String textBody, GenericHttpMediaType genericMediaType) throws HttpClientException {
RequestBody body = RequestBody.create(okHttpMediaType, textBody);
Request postRequest = new Request.Builder().url(url).post(body).build();
Call postCall = okHttpClient.newCall(okHttpRequest);
Response postResponse = postCall.execute();
return GenericHttpResponse
.builder()
.body(okHttpResponse.body().string())
.headers(okHttpResponse.headers().toMultimap())
.code(okHttpResponse.code())
.build();
}
This failure is only happening for large response sizes. As per the server logs, the response size (after gzip encoding) is around 52MB, but the call is still failing. This same code has been working fine for response sizes around 10-15MB.
I tried replicating the same issue through a simple cURL call, but that ran successfully:
curl -v -s --request POST 'http://<hasura_endpoint>/v1/graphql' \
--header 'Content-Type: application/json' \
--header 'Accept-Encoding: gzip, deflate, br' \
--data-raw '...'
* Trying ::1...
* TCP_NODELAY set
* Connected to <host> (::1) port <port> (#0)
> POST /v1/graphql HTTP/1.1
> Host: <host>:<port>
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Type: application/json
> Accept-Encoding: gzip, deflate, br
> Content-Length: 1840
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
} [1840 bytes data]
* We are completely uploaded and fine
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Date: Tue, 27 Apr 2021 11:59:24 GMT
< Server: Warp/3.3.10
< x-request-id: 27e3ff3f-8b95-4328-a1bc-a5492e68f995
< Content-Type: application/json; charset=utf-8
< Content-Encoding: gzip
<
{ [6 bytes data]
* Connection #0 to host <host> left intact
* Closing connection 0
So I'm assuming that this error is specific to the Java client.
Based on suggestions provided in similar posts, I tried the following other approaches:
Adding a Connection: close header to the request
Sending Transfer-Encoding: gzip header in the request
Setting the retryOnConnectionFailure for the OkHttp client to true
But none of these approaches were able to resolve the issue.
So, my questions are:
What could be the underlying cause for this issue? Since I'm using chunked transfer encoding here, I suppose it's not due to an incorrect content-length header passed in the response.
What are the approaches I can try for debugging this further?
Would really appreciate any insights on this. Thank you.
I'm a DIYer and I'm trying to upload a picture from ESP32-CAM to imgbb.com using POST. This project from RandomNerdTutorials gave me a better notion about POST request on C++.
I took their code and modified it to upload to https://api.imgbb.com.
/*
Rui Santos
Complete project details at https://RandomNerdTutorials.com/esp32-cam-shield-pcb-telegram/
Project created using Brian Lough's Universal Telegram Bot Library: https://github.com/witnessmenow/Universal-Arduino-Telegram-Bot
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
*/
// Partial code modified to upload to imgbb.com
String uploadPhoto(char *apikey){
String getAll = "";
String getBody = "";
camera_fb_t * fb = NULL;
fb = esp_camera_fb_get();
if(!fb) {
Serial.println("Camera capture failed");
delay(1000);
ESP.restart();
return "Camera capture failed";
}
Serial.println("Connect to api.imgbb.com");
if (clientTCP.connect("api.imgbb.com", 443)) {
Serial.println("Connection successful");
String head = "--RandomNerdTutorials\r\nContent-Disposition: form-data; name=\"photo.jpg\"; filename=\"photo.jpg\"\r\nContent-Type: image/jpeg\r\n\r\n";
// String head = "--RandomNerdTutorials\r\nContent-Disposition: form-data; name=\"photo.jpg\"; filename=\"photo.jpg\"\r\n\r\n";
String tail = "\r\n--RandomNerdTutorials--\r\n";
uint16_t imageLen = fb->len;
uint16_t extraLen = head.length() + tail.length();
uint16_t totalLen = imageLen + extraLen;
Serial.printf("imageLen:%d - extraLen: %d - totalLen: %d\n", imageLen, extraLen, totalLen);
clientTCP.println("POST /1/upload?expiration=600&key="+String(apikey)+" HTTP/1.1");
clientTCP.println("Host: api.imgbb.com");
clientTCP.println("Content-Length: " + String(totalLen));
clientTCP.println("Content-Type: multipart/form-data; boundary=RandomNerdTutorials");
clientTCP.println();
clientTCP.print(head);
uint8_t *fbBuf = fb->buf;
size_t fbLen = fb->len;
Serial.printf("fbLen: %d\n", fbLen);
int count = 0;
for (size_t n=0;n<fbLen;n=n+1024) {
count++;
Serial.printf("Sending part %d\n", count);
if (n+1024<fbLen) {
clientTCP.write(fbBuf, 1024);
fbBuf += 1024;
}
else if (fbLen%1024>0) {
size_t remainder = fbLen%1024;
clientTCP.write(fbBuf, remainder);
}
}
clientTCP.print(tail);
esp_camera_fb_return(fb);
unsigned long now = millis();
boolean state = false;
while (millis() - now < 10000){ // timeout 10 seconds
Serial.print(".");
delay(100);
while (clientTCP.available()){
char c = clientTCP.read();
if (c == '\n'){
if (getAll.length()==0) state=true;
getAll = "";
}
else if (c != '\r'){
getAll += String(c);
}
if (state==true){
getBody += String(c);
}
}
if (getBody.length()>0) break;
}
clientTCP.stop();
Serial.println(getBody);
}
else {
getBody="Connected to api.imgbb.com failed.";
Serial.println("Connected to api.imgbb.com failed.");
}
return getBody;
}
I get this on Serial Monitor
Connection successful
imageLen:7522 - extraLen: 150 - totalLen: 7672
fbLen: 7522
Sending part 1
Sending part 2
Sending part 3
Sending part 4
Sending part 5
Sending part 6
Sending part 7
Sending part 8
..
7a
{"status_code":400,"error":{"message":"Empty upload source.","code":130,"context":"Exception"},"status_txt":"Bad Request"}
In case you are asking for the cURL example output on their API site, the output using -v option prints:
With command
curl --location --request POST "https://api.imgbb.com/1/upload?expiration=600&key=YOUR_CLIENT_API_KEY" --form image=#"example.jpg" -v
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 51.81.57.189...
* TCP_NODELAY set
* Connected to api.imgbb.com (51.81.57.189) port 443 (#0)
* schannel: SSL/TLS connection with api.imgbb.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 178 bytes...
* schannel: sent initial handshake data: sent 178 bytes
* schannel: SSL/TLS connection with api.imgbb.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with api.imgbb.com port 443 (step 2/3)
* schannel: encrypted data got 3525
* schannel: encrypted data buffer: offset 3525 length 4096
* schannel: sending next handshake data: sending 93 bytes...
* schannel: SSL/TLS connection with api.imgbb.com port 443 (step 2/3)
* schannel: encrypted data got 51
* schannel: encrypted data buffer: offset 51 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with api.imgbb.com port 443 (step 3/3)
* schannel: stored credential handle in session cache
> POST /1/upload?expiration=600&key=1be33137765dd807cb05b2ff94885779 HTTP/1.1
> Host: api.imgbb.com
> User-Agent: curl/7.55.1
> Accept: */*
> Content-Length: 18608
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=------------------------c67a7796e0413135
>
* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 54
* schannel: encrypted data buffer: offset 54 length 103424
* schannel: decrypted data length: 25
* schannel: decrypted data added: 25
* schannel: decrypted data cached: offset 25 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 25 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 25
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 100 Continue
HTTP/1.1 100 Continue
* schannel: client wants to read 102400 bytes
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 1096
* schannel: encrypted data buffer: offset 1096 length 103424
* schannel: decrypted data length: 1067
* schannel: decrypted data added: 1067
* schannel: decrypted data cached: offset 1067 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 1067 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 1067
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx
Server: nginx
< Date: Mon, 10 Aug 2020 20:08:42 GMT
Date: Mon, 10 Aug 2020 20:08:42 GMT
< Content-Type: application/json; charset=UTF-8
Content-Type: application/json; charset=UTF-8
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
< Connection: keep-alive
Connection: keep-alive
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: Cache-Control, X-Requested-With, Content-Type
Access-Control-Allow-Headers: Cache-Control, X-Requested-With, Content-Type
< Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Methods: POST, GET, OPTIONS
< Last-Modified: Mon, 10 Aug 2020 20:08:42GMT
Last-Modified: Mon, 10 Aug 2020 20:08:42GMT
< Cache-Control: no-cache, must-revalidate
Cache-Control: no-cache, must-revalidate
< Pragma: no-cache
Pragma: no-cache
<
{"data":{"id":"P6Ynw91","title":"pull","url_viewer":"https:\/\/ibb.co\/P6Ynw91","url":"https:\/\/i.ibb.co\/d5cqGLk\/pull.jpg","display_url":"https:\/\/i.ibb.co\/d5cqGLk\/pull.jpg","size":18421,"time":"1597090122","expiration":"600","image":{"filename":"pull.jpg","name":"pull","mime":"image\/jpeg","extension":"jpg","url":"https:\/\/i.ibb.co\/d5cqGLk\/pull.jpg"},"thumb":{"filename":"pull.jpg","name":"pull","mime":"image\/jpeg","extension":"jpg","url":"https:\/\/i.ibb.co\/P6Ynw91\/pull.jpg"},"delete_url":"https:\/\/ibb.co\/P6Ynw91\/7912eb21dadf18bcf78119d10ae7b427"},"success":true,"status":200}* Connection #0 to host api.imgbb.com left intact
You only need to modify the parameter name of imageField to "image".
form-data; name=\"image\"; filename=\"photo.jpg\"
https://api.imgbb.com/
Parameters
image (required)
A binary file, base64 data, or a URL for an image. (up to 32 MB)
String head = "--RandomNerdTutorials\r\nContent-Disposition: form-data; name=\"expiration\"; \r\n\r\n600\r\n--RandomNerdTutorials\r\nContent-Disposition: form-data; name=\"key\"; \r\n\r\n" + String(apikey) + "\r\n--RandomNerdTutorials\r\nContent-Disposition: form-data; name=\"image\"; filename=\"photo.jpg\"\r\nContent-Type: image/jpeg\r\n\r\n";
clientTCP.println("POST /1/upload HTTP/1.1");
I'm trying to emulate a curl -X GET with Go, but the server I'm contacting has authentication. I've followed several sites that recommend me to use r.Header.Add(), but I can't get my curl call to work.
My curl call that actually returns something:
curl -X GET https://myserver.com/test/anothertest -H 'x-access-token: a1b2c3d4'
My code that doesn't return the expected JSON object:
func get(api string, headers map[string]string, dataStruct interface{}) (data interface{}, err error) {
req, _ := http.NewRequest("GET", api, nil)
for k, v := range headers {
req.Header[k] = []string{v}
}
currentHeader, _ := httputil.DumpRequestOut(req, true)
fmt.Println(string(currentHeader))
client := &http.Client{}
resp, err := client.Do(req)
if err != nil {
return
}
defer resp.Body.Close()
data = dataStruct
err = getJson(api, &data)
if err != nil {
return
}
return
}
func main() {
// args := parse_args(Options{})
args := Options{Api: "my_server",
Headers: map[string]string{
"x-access-token": "a1b2c3d4"}}
body, _ := get(args.Api, args.Headers, HistoryDecoder{})
fmt.Println(body)
}
Returns:
GET /v1pre3/users/current HTTP/1.1
Host: my_server
User-Agent: Go-http-client/1.1
X-Access-Token: a1b2c3d4
Accept-Encoding: gzip
map[ResponseStatus:map[Message:Please ensure that valid credentials are being provided for this API call (This request requires authentication but none were provided)] Notifications:[map[Type:error Item:Please ensure that valid credentials are being provided for this API call (This request requires authentication but none were provided)]]]
Could anyone please tell me what I'm doing wrong?
edit adding curl -v response
* About to connect() to my_server port 443 (#0)
* Trying 54.210.110.53...
* Connected to my_server (54.210.110.53) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=*.cloud-test.com
* start date: Feb 28 00:00:00 2018 GMT
* expire date: Mar 28 12:00:00 2019 GMT
* common name: *.cloud-test.com
* issuer: CN=Amazon,OU=Server CA 1B,O=Amazon,C=US
> GET /v1pre3/users/current HTTP/1.1
> User-Agent: curl/7.29.0
> Host: my_server
> Accept: */*
> x-access-token: a1b2c3d4
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache, no-store, must-revalidate
< Content-Type: application/json
< Date: Tue, 30 Oct 2018 15:49:00 GMT
< Expires: 0
< Pragma: no-cache
< Server:
< x-capabilities: audit
< X-Content-Type-Options: nosniff
< X-Request-ID: 2018.10.30.15.49.00.9zHjdeQ-ZEmg2IvzTymnxQ
< transfer-encoding: chunked
< Connection: keep-alive
<
* Connection #0 to host my_server left intact
After a lot of rewriting and debugging, I figured out that getJson(api, &data) was also making a http.Get call but without headers. Since that took place after the request we were discussing, it bypassed all testing and printing.
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.
I'm trying to get server-sent events set up in Clojure with Aleph, but it's just not working over IPv4. Everything is fine if I connect over IPv6. This occurs both on Linux and MacOS. I've got a full example of what I'm talking about on GitHub.
I don't think I'm doing anything particularly fancy. The whole code is up on GitHub, but essentially my program is:
(def my-channel (permanent-channel))
(defroutes app-routes
(GET "/events" []
{:headers {"Content-Type" "text/event-stream"}
:body my-channel}))
(def app
(handler/site app-routes))
(start-server (wrap-ring-handler app) {:port 3000}))
However, when I connect to 127.0.0.1:3000, I can see curl sending the request headers, but it just hangs, never printing the response headers:
$ curl -vvv http://127.0.0.1:3000/events
* About to connect() to 127.0.0.1 port 3000 (#0)
* Trying 127.0.0.1...
* Adding handle: conn: 0x7f920a004400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f920a004400) send_pipe: 1, recv_pipe: 0
* Connected to 127.0.0.1 (127.0.0.1) port 3000 (#0)
> GET /events HTTP/1.1
> User-Agent: curl/7.30.0
> Host: 127.0.0.1:3000
> Accept: */*
If I connect over IPv6 the response comes right away, and events that I enqueue in the channel get sent correctly:
$ curl -vvv http://localhost:3000/events
* Adding handle: conn: 0x7f943c001a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f943c001a00) send_pipe: 1, recv_pipe: 0
* About to connect() to localhost port 3000 (#0)
* Trying ::1...
* Connected to localhost (::1) port 3000 (#0)
> GET /events HTTP/1.1
> User-Agent: curl/7.30.0
> Host: localhost:3000
> Accept: */*
>
< HTTP/1.1 200 OK
* Server aleph/0.3.0 is not blacklisted
< Server: aleph/0.3.0
< Date: Tue, 15 Apr 2014 12:27:05 GMT
< Connection: keep-alive
< Content-Type: text/event-stream
< Transfer-Encoding: chunked
I have also reproduced this behaviour in Chrome. In both the IPv4 and IPv6 cases, tcpdump shows that the response headers are going over the wire.
This behaviour occurs both with lein run and an uberjar. It also occurs if I execute the uberjar with -Djava.net.preferIPv4Stack=true.
How do I get my application to behave the same over IPv4 as over IPv6?