Re: Strange Problem with NSData and RDF Feeds

FROM : David Christensen
DATE : Mon Apr 11 00:19:56 2005

Alex,

You've got a stream which is gzipped (/usr/share/file/magic confirms
the magic number at the start of the stream).  It may be that the
transfer was incomplete, leading to a buffer in an undefined state (ie,
should have been uncompressed, but because the full transfer did not
take place, it was not).  It may be that you can customize the outgoing
headers in the raw HTTP request; it's been a while since I've used the
NSURL stuff, definitely pre-10.3.  I believe the one that you are
interested in is "Accept-encoding:".  You would need to omit this
header, if possible, or set it to some default value.

HTH,

David

-----
David Christensen
Founder and CTO
Yin Yan Software

On Apr 10, 2005, at 9:31 AM, Alex v.Below wrote:

> Hello,
>
> Given that the post may be lengthy, here is a
>
> SUMMARY: NSData seems to have problems reading specific URLs pointing
> to RDF feeds. However other parts of the framework have no problem
> correctly generating XML from the URL. To add to the confusion,
> hosting the feed on another server will remedy the problem as well.
>
>
> I have encountered a problem I find most puzzling. Probably it is not
> even a Cocoa issue, but I would like to start my investigation here.
>
> The following code reads the rdf feed from the very popular German
> tech news site "heise.de" into an NSData object:
>
>     url = [NSURL
> URLWithString:@"http://www.heise.de/newsticker/heise.rdf"];
>     data = [NSData dataWithContentsOfURL:url];
>
> The data returned only has 750 bytes (which is too short), and when
> inspecting the data (or writing it out to a file) I can not make out
> any structure:
>
> 0000000: 1f8b 0800 0000 0000 0003 a556 4d53 db30  ...........VMS.0
> 0000010: 10bd e757 ecb8 e758 2640 2119 13a6 2985  ...W...X&@!...).
> [...]
>
> In comparison, this is the start of the expected data:
>
> 0000000: 3c3f 786d 6c20 7665 7273 696f 6e3d 2231  <?xml version="1
> 0000010: 2e30 2220 656e 636f 6469 6e67 3d22 4953  .0" encoding="IS
> [...]
>
> And here are the odd details:
>
> - Reading most other URLs is no problem
>     I found only one other feed,
> http://ftd.de/static/ticker/ftd-topnews.rdf, with a similar error.
> Reading other locations works as expected
>
> - curl reads the feed without problems
>     curl - http://www.heise.de/newsticker/heise.rdf will generate an
> XML:RDF document as expected.
>
> - Reading the same data  from other servers works
>     When hosting the data acquired with curl locally or on my
> own web-server (Apache/Debian), the problem does not occur.
>
> - CFXMLTreeCreateWithDataFromURL works without error
>     When passing the URL to CFXMLTreeCreateWithDataFromURL (or more
> recent XML handling methods, wink,wink, knowwhaddamean?), the feed is
> read and interpreted correctly. A valid XML document is returned.
> Needless to say, passing the data object  read with
> dataWithContentsOfURL: from the original location will produce an
> error.
>
> - RSS Readers read the feed correctly
> Not too amazing, the RSS readers I have tested work without error on
> the original feed. This includes the w3 RDF Validator
> (http://www.w3.org/RDF/Validator )
>
> So while the fact that hosting the document on another server remedies
> the issue may point to a configuration issue of the remote server,
> other applications, tools and parts of the framework such as the
> CoreFoundation XML Parser and "some technology still under NDA" seem
> to work flawless. How do they acquire the data if not by leveraging
> the same code?
>
> Then why do you want to use NSData if CFXMLTree does it? Some of you
> might ask. Good question. I wanted to pass the data
> to CFXMLTreeCreateFromDataWithError which returns an error dict. There
> is no corresponding function for passing a URL directly and getting
> the error.
>
> Is this a server problem? Is this a Cocoa problem? Is there a
> workaround?
>
> Thanks for your help!
>
> Alex
>
> _______________________________________________
> MacOSX-dev mailing list
> <email_removed>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>