Won't Fix
Last Updated: 09 Jul 2025 05:25 by ADMIN
pookyung
Created on: 19 Jun 2025 01:49
Type: Bug Report
0
close_notify issue when response does not have Content-Length and Content-Type

Hi, Support

When I use Fiddler Classic as a proxy in my program that uses SugarSync API, data reception fails due to sudden disconnection.

If I receive directly from the API server without going through Fiddler, there is no problem.
Whether it is a direct connection or Fiddler, the header and data of the server response are all the same.

When I look at Fiddler, all data is received, but when my program tries to get the data in the response, my Rebex Engine throws an error "Connection was closed by the remote connection end."

I also contacted Rebex, and they said that it is a close_notify error, so Fiddler does not handle it correctly.
In other words, I need to receive data after making a SugarSync API call, but the connection is disconnected without receiving a close_notify, so an error occurs when receiving data.

There is no problem in general when using Fiddler, but it only occurs when connecting to the SugarSync API server.

SugarSync API does not send Content-Length header and  Content-Type header in response.

In my opinion, since there is no Content-Length or Content-Type in the header, it seems that Fiddler suddenly disconnects the client.

I hope this report will help you improve your product.

 

Thank you,

Best regards

BooKyung Oh



Fiddler Capture (Some data and information has been truncated and marked as ...)

Request : 
POST https://api.sugarsync.com/authorization HTTP/1.1
Host: api.sugarsync.com
Content-Type: application/xml; charset=utf-8
Content-Length: 290
User-Agent: ...
Connection: keep-alive

<tokenAuthRequest>...</tokenAuthRequest>


Response : 
HTTP/1.1 201 Created
Content-Type: application/xml; charset=UTF-8
Date: Sat, 14 Jun 2025 02:48:36 GMT
Location: ...
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Requested-With,Content-Type,Content-Length,Authorization,Range,X-SugarSync-API-Version
Access-Control-Expose-Headers: Location,Content-Disposition,Content-Length,Accept-Ranges,Date,Transfer-Encoding,Vary
Access-Control-Max-Age: 259200
Access-Control-Allow-Methods: GET,POST,DELETE,PUT
Server: Noelios-Restlet-Engine/1.1.5
Connection: close

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><authorization><expiration>2025-06-13T20:48:36.533-07:00</expiration><user>https://api.sugarsync.com/user/...</user></authorization>



2 comments
Eric
Posted on: 08 Jul 2025 18:50

This response specifies `Connection: close` which means that the response is completed when the server closes the connection. Fiddler sees that and correctly interprets the server's connection closure as the end of the response, and it subsequently returns the server's response to the client and then Fiddler in turn closes its connection to that client.

`close_notify` is a TLS message sent on a TLS connection indicating that the connection will be closed. It's not clear from your message is whether the upstream server is sending such a message (Fiddler and the vast majority of web clients do not care).

If the vendor is correct (which I would not necessarily believe without seeing a PCAP from their web server myself) then, yes, it's possible that Fiddler is the culprit here. A little bit of looking suggests that .NET's SslStream class does not sent `close_notify` messages when a SslStream is closed. https://github.com/dotnet/runtime/issues/44660

(To be clear, chunked encoding is signaled by "Transfer-Encoding: chunked", not by Content-Type.)

 

 

pookyung
Posted on: 19 Jun 2025 02:12
No Content-Type means it is not chunked.