• 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: Odd NSData initWithContentsOfURL: issue
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Odd NSData initWithContentsOfURL: issue


  • Subject: Re: Odd NSData initWithContentsOfURL: issue
  • From: Nicko van Someren <email@hidden>
  • Date: Thu, 17 Mar 2005 20:40:49 +0000

On 15 Mar 2005, at 20:01, John Stiles wrote:
On Mar 15, 2005, at 11:46 AM, John C. Randolph wrote:
On Mar 13, 2005, at 10:01 PM, Nicko van Someren wrote:
...
It seems that there is a real bug in the initWithContentsOfURL: code for NSData and NSString and by extension every class that uses them. A quick check of the headers sent with the request shows that they include:
Accept-Encoding: gzip, deflate;q=1.0, identity;q=0.5, *;q=0
...
I will file a bug report with Apple. Given that 10.3.9 is in seed already I guess it won't get fixed before Tiger :-(

That would be a feature request, rather than a bug report. -initWithContentsOfURL: is supposed to give you whatever's at that URL, without any modifications.

The problem is is does not do that. There is no compressed data at that URL.


I think most users would argue that the compression of the data is an artifact of the transport mechanism, and does not represent the actual data at that URL. And you should not be explicitly advertising gzip support to the server on the client's behalf if you aren't going to take responsibility for the actual gzip decompression.

Absolutely. The data is not compressed on the server and it is only being compressed in transit at the (erroneous) request of the client. If you make an access to the same URL using, say, wget, you get the raw data. If you access the URL with Safari and display the source you get the raw data. If you access the URL with initWithContentsOfURL your get the compressed transport stream and not the data at the URL.


The compression of the data is an un-requested artefact of the manner in which initWithContentsOfURL asks for the data. There is no way for the user to know in advance if the server supports compression and therefore will be effected by the Accept-encoding: header line that gets sent. Do you honestly think that this is a feature, let alone a useful one, and not a honest-to-goodness bug?

	Nicko

_______________________________________________
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


References: 
 >Odd NSData initWithContentsOfURL: issue (From: "Michael J. Sherman" <email@hidden>)
 >Re: Odd NSData initWithContentsOfURL: issue (From: Nicko van Someren <email@hidden>)
 >Re: Odd NSData initWithContentsOfURL: issue (From: "John C. Randolph" <email@hidden>)
 >Re: Odd NSData initWithContentsOfURL: issue (From: John Stiles <email@hidden>)

  • Prev by Date: KVO and isKindOfClass:
  • Next by Date: Re: KVO and isKindOfClass:
  • Previous by thread: Re: Odd NSData initWithContentsOfURL: issue
  • Next by thread: Re: Odd NSData initWithContentsOfURL: issue
  • Index(es):
    • Date
    • Thread