Simon Fell > Its just code > July 2003

stands for "Pie isn't echo" - Xian. Love it!, gets my vote

Congrats to Joe on the formation of his Custom System Development company Bitworking, Inc.

Following Sam's suggestion, my Atom feed now has unencoded content where possible, with relative urls.

I've been thinking about Sam's suggestion for how to provide unencoded content in my atom feed, in looking at his example, I spotted one problem, the second content entry, which is an unencoded text/html part has the html tags in the atom namespace.

<feed xmlns="http://example.com/newformat#" xmlns:ent="http://www.purl.org/NET/ENT/1.0/" version="1.0">
...
<content type="text/html" xml:lang="en-us">
      <p>Hello, <em>weblog</em> world! 2 &lt; 4!</p>
</content>

The <p> being in the default namespace of http://example.com/newformat#. Another validation on my stance that default namespaces are evil.

Someone please fix the braindead implementation that loads the whole file into memory before returning it to the client.

I've update my Atom/Pie feed to use relative Urls.

Over on the PocketSOAP mailing list I'm looking for feedback about backwards compatibility for PocketSOAP 2.0. Speak now!

Digging though http compression again, found Ben Lowery's HttpCompressionModule for ASP.NET, which works great, except for one bug, it doesn't take caching into account. Fortunately its easy to fix, in HttpCompressionModule,CompressContent add app.Context.Response.Cache.VaryByHeaders["Accept-Encoding"] = true ; after the HttpApplication app = (HttpApplication)sender; (line 58 in HttpCompressionModule.cs) and you're good to go!. GetFilterForScheme could also do with some work to apply q values properly when trying to determine which compression scheme to use, but practically speaking, that's a very minor problem.

I've also been looking at the compression handling in PocketHTTP, and spotted a problem, seems the http spec/implementations aren't very clear on whether a deflate encoded response should include the 2 byte zlib header or not, sigh. Currently PocketHTTP will only handle deflate responses that include the header, you'll get deflate data errors if you get a response without the header (such as from IIS6.0). The fix will be in CVS by the end of the weekend.

Just sent my first external SOAP 1.2 request against Bob's White Mesa SOAP 1.2 test service.

POST /soap12/test-rpc-lit HTTP/1.1
Host: www.whitemesa.net
Accept-Charset: UTF-8, UTF-16;q=0.8, iso-8859-1;q=0.8
Accept-Encoding: deflate
Content-Type: application/soap+xml; charset="utf-8"; action="http://soapinterop.org/"
User-Agent: PocketSOAP/2.0/alpha1
Content-Length: 347

<E:Envelope
	xmlns:a="http://soapbuilders.org/rpc-lit-test"
	xmlns:XS="http://www.w3.org/2001/XMLSchema"
	xmlns:XI="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:E="http://www.w3.org/2003/05/soap-envelope"><E:Body>
<a:echoString><inputString XI:type="XS:string">hello world from PocketSOAP</inputString>
</a:echoString></E:Body></E:Envelope>

HTTP/1.1 200 OK
Date: Sat, 26 Jul 2003 19:57:11 GMT
Server: WhiteMesa SOAP Server/3.2
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: 394
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope">
<SOAP-ENV:Body><m:echoStringResponse xmlns:m="http://soapbuilders.org/rpc-lit-test">
<SOAP-RPC:result xmlns:SOAP-RPC="http://www.w3.org/2003/05/soap-rpc">return</SOAP-RPC:result>
<return>hello world from PocketSOAP</return>
</m:echoStringResponse>
</SOAP-ENV:Body></SOAP-ENV:Envelope>

ASP.NET has a feature that limits the size of a HTTP request message, as part of an attempt to reduce possible DOS attacks. The exact limit (which defaults to 4MB) can be changed by adding an entry to your web.config file.

All good, until you start looking at file uploads, then you realize that the way in which the large request error is managed, makes it just about impossible to do a user friendly upload form, that will report if they attempt to upload a file larger than allowed. It seems that once ASP.NET sees the request go over the limit, it responds with a 400 bad request error, there's no way from your .aspx page code to trap this and do anything more friendly with it. IE shows the horrible no server or DNS error message when faced with a 400 error, unless you also have smart Navigation turned on, in which case the smartNav frame seems to hide the error page, and the user is left looking at the page they were on with no indication as to what's going on. Mozilla gives a "response contained no data" error message, whilst Firebird, does some strange looking lookup to find a new site to look at (i.e. if this url http://coldcut/scripts/upload.aspx returns the 400 error, firebird redirects me to ningatunes.net/coldcut/ !).

I googled around, but didn't spot any workable solutions. I did find however that if you get in and check the contentlength early enough, you can redirect to a different page to show the user more reasonable error message. You can't do it from the page, but if you handle the BeginRequest event from a custom module or from the global.asax and check it there, it'll work.

ASP.NET is a massive step up from ASP, but it still has some rough edges, I hope they get sorted out for the next release.

Joe is keeping busy on the AtomAPI, and has posted another rev. It feels a lot like the RESTLog now, which is a good thing in my book. He also has an interesting post on the single API URL vs URL per entry issue, and shows that its actually easier to code the multiple URL with HTTP verbs version. I found the same thing when I was working on my RESTLog.NET implementation, which uses a single ASP.NET handler factory to handle all the RESTLog related requests.

• Congrats to Keith & Co on the WSE 2 Tech Preview.
• More new software, congrats to Dave & co for SOAPScope 2 beta 2. Looking forward to trying both this and WSE2 out.
• Just finished reading Chasm City, way way better than Revalation Space. Tempted to try Redepemtion Ark now.
• Saw some awesome Lebbeus Wood's drawings at SFMoma over the weekend, will have to track some more of his stuff down.
• The history (and mystery) of the universe is still running over at Project Artaud, I loved it, highly recommended.

I just finished coding up support for the CommentAPI in Syndirella, it supports both wfw:comment (post comments directly from Syndirella) and wfw:commentRss (subscribe to comments on this topic). As soon as SourceForge CVS is working, it'll be available.

I've been reading Joe's draft Eco API doc, here's some comments (posted here, because following the wiki is just getting impossible for me, YMMV)

• Instrospection
• what are all the valid element names for the introspection document?
• can i extend this with Namespace qualified elements?
• shouldn't this document be in a namespace?
• are fully qualified URLs required, can i use relative URLs instead? xml:base?
• Creating a new entry
  • Why does creating a new entry goto the <edit-entry/> URL whilst updating an existing entry goto the <create-entry/> URL, based on the surounding text, I'd expect them both to go the <create-entry/> url
  • in 4.2.1 the GET example, shouldn't the Content-Type header be an Accept header?
• Deleting an entry should use the HTTP DELETE method.
• Are the user prefs going to be defined, or is that upto the different apps?

I'm not really a fan of the do everything over POST approach, i think RESTLogs use of POST/PUT/DELETE is much better. But now that everything is a POST, going to a SOAP version will be trivial.

There's now a valid (formerly known as | not) echo feed for this weblog. I would hope that the namespace gets set soon, so far I've seen about 5 variations.

Microsoft is a founding member of the WS-I, and one of the biggest proponents of doc/literal "it's just data" style SOAP, everywhere you look on the MSDN Web Services center its doc/literal SOAP is great, everything else is useless. They also have this new, built from the ground up in .NET product MS-CRM, its a big ticket item, it has a web services interface for pretty much everything. So, WTF is it doing section 5 encoded SOAP ? why is it shipping XML docs around encoded as strings in a section 5 encoded soap message. Arrrrggghhhhhhh, why, if its built on .NET doesn't it use the ASMX engine, no lets build yet another SOAP stack, lets forget to put the charset attribute on the response content-type. Why isn't there a WSDL description of the services. Someone (Keith, Don, Yasser), please go show these guys the clue stick.

There's a post on Sams blog about whether to use xml-rpc, soap and/or rest for the (not)echo weblogging API. And a raging discussion on the Wiki as well. Having implemented the Blogger API, Metaweblog API and RESTLog in the past, I'm all for a RESTful HTTP interface, no SOAP, no XML-RPC. No toolkit required. RESTLog (which follows that model) was by far the simplest of the 3 to develop / debug / get interop.