Zend HTTP Woes

The Zend Framework HTTP Client is both a blessing and a curse. While it adds a lot of capabilities and a decent abstraction (from cURL or fsock), it also has a lot of bugs from what I’m assuming to be due to its young age and being mostly used for internal applications. Let me explain a few of the more glaring ones so you can work around them as well:

Poor GZ Decoding

Many sites use GZ compression on the wire which nearly all HTTP clients know how to decompress / inflate. Within Zend_Http_Response is a call to gzinflate() for this purpose, but the call does not give a maximum length and I’ve seen it fail a large number of pages which show up properly in Firefox. I don’t know what the issue is with the latter, but it seems tied to the former. When gzinflate() improperly decodes the data, it sometimes tries to allocate an exorbitant amount of bytes and thus PHP goes full-stop on an “out of memory” error. I modified my copy of the class to only allocate up to 1mb (hacky fix).

Content-Length at Face Value

Much like the GZ problem, the socket adapter accepts Content-length headers at face value and blindly attempts to allocate that much memory. Again, my fix was to limit the allocation to what was left or throw an exception.

Dirty Headers

Keeping one instance of Zend_Http_Client is convenient, but you must remember to nullify headers you’ve set (or do that before your request). Two in particular which sent me through debugging hell today are Referer (yes, it’s misspelled) and Host. The resetParameters() method does not effect headers, so subsequent requests will pass the same information.

Note: I’m using Zend Framework 1.8.4; hopefully the future will mean the end of these problems.

Week 6: Ratings

This week’s stage is about giving more control to general visitors, anonymous included.  Any user is thus able to “Approve” or “Delete” any segment which can be seen as voting up or down.  Unless this person is the author or a moderator, other users will not see the results of these actions, but they are saved.  Back in the planning stage I was going to save this data in a local cookie, but now all of it is being kept in S3.  All of it.  And I won’t be displaying any raw numbers or using it in a much-meaningful way now, but I intend to (down the road) use it for democratic moderation along the lines of Digg, HN, etc.

So the work this week is minimal: open the “moderate” operation to all users and potentially rename it to something like “visibility” since it’s all about setting the ‘v’ (visibility) leaf value.  Interpreting the ‘v’ leaf needs to be a bit more advanced, taking into account the current user, author, and moderator values.  I’d like to expand the XHTML rendering to omit hidden segments entirely and have them loaded by jQuery if the user clicks a button to show them.

I may spend extra time improving comment functionality.  Specifically an author or moderator must have the ability to approve/delete them.  Comments have very little information to them since each one is an individual leaf in a leaf list (leaflet?), whereas segments can have multiple leaves.  I think democratic moderation of comments is the only way to go.  If you don’t want others hiding your comments, then you can author your own page; easy as that.  Anyway, saving moderation data on comments will most likely be in the form of a single leaf for that user on that particular segment which indicates which comments they approved/deleted.

If a user deletes their own comment then it is set to blank in order to completely “retract” it.

For new pages, users should be able to suggest a title.  This is the title that is used for them and potentially displayed for moderators as a drop-down when performing the mod.categorize operation.

Finally, I’m debating the allowance of external links in the “link” operation which is currently only available to moderators.  If users can add external links, I can see it being mightily abused and difficult to keep relevant or moderated, democratically or not.  The functionality would be extremely helpful for FanSiter, however.

Authorship and Editing

Today I completed the final feature for the authorship stage: editing.

AJAX-loaded edit form; text is initialized to previous value.

This brings me up to having done the following:

• Saving UID on S3 objects.
• Locking (all or just comments).
• Moderation (approve/hide); there’s a bug here which gives the author too much power, but I can fix it later.
• Editing.

As has been the case, the code and output is very rough, but it does what I set out to make it do.  Hurray!