• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CFSocket freezes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CFSocket freezes


  • Subject: Re: CFSocket freezes
  • From: Chilton Webb <email@hidden>
  • Date: Sun, 27 Nov 2005 20:43:16 -0600

Hi Daniel,

Thank you for your reply.

On Nov 27, 2005, at 6:37 PM, Daniel Jalkut wrote:

Chilton, when you say it's "not working at all", what do you mean exactly? Doesn't build, doesn't run, runs but errors out, runs but doesn't seem to serve pages? If you run the test project and then telnet to the appropriate port, you should be able to easily confirm whether or not it's "answering the phone":
Sorry, I should have been more clear. It builds fine, and connects fine. And now that I know where to put the file, it appears to work somewhat fine, at least for files that exist. By 'working', I meant that it was not handling the event properly. Exactly where, or why, I didn't know.

% telnet localhost 64942
GET /whatever.html HTTP/1.1

Yields:

HTTP/1.1 404 Not Found

Make sure you hit return twice after the "GET" line. Alternately, you can use tcpdump to monitor the loopback activity while you test acessing the server through a web browser:

% sudo tcpdump -Atq -s 0 -i lo0

When diagnosing network code, I prefer this... sudo tcpdump -X -s 0 -i lo0

The combination of hex and ASCII lets me see things that aren't readily apparent, such as line endings.

However, if you try telnetting into the Cocoa httpserver, you'll notice something else, compared to any other http server...

I narrowed this down to the omission of the "Content-Length" header in CocoaHTTPServer's empty error resopnses. For example, I added the following line:

CFHTTPMessageSetHeaderFieldValue(response, (CFStringRef)@"Content- Length", @"0");

In performDefaultRequestHandling, after attaching a 404 error response to the message. This seems to be sufficient to notify the client (Safari) that the message is complete. Otherwise, it would seem that it is waiting for the indeterminately sized message body to come across the pipe.

Could that be related to the problems you folks are seeing?
Well, that does appear to be the problem for Safari. Safari reads this, and appears to sever the connection after receiving it. That might be how the spec works, come to think of it. But for my other http diagnostics tools, it does not entirely fix the problem.

It appears the problem is that the server is not closing the connection. Telnetting into the server shows that after it replies, it does not close the connection. Most (if not all) http servers do close the connection, immediately after sending the reply. Does anyone know why it's not doing this in the Cocoa example?

And thanks for the Netcat tip. That's one I didn't know about.

-Chilton
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: CFSocket freezes
      • From: Daniel Jalkut <email@hidden>
References: 
 >CFSocket freezes (From: Frank Illenberger <email@hidden>)
 >Re: CFSocket freezes (From: Felix Schwarz <email@hidden>)
 >Re: CFSocket freezes (From: Uli Kusterer <email@hidden>)
 >Re: CFSocket freezes (From: Chilton Webb <email@hidden>)
 >Re: CFSocket freezes (From: Daniel Jalkut <email@hidden>)

  • Prev by Date: Re: Is Apple's singleton sample code correct?
  • Next by Date: Finding the user's processor type...
  • Previous by thread: Re: CFSocket freezes
  • Next by thread: Re: CFSocket freezes
  • Index(es):
    • Date
    • Thread