If there is an uncached page that a user tries to share on facebook, it fails to return it properly. (See screenshots)

If boost is disabled, the page returns correctly always. Changing the gzip settings does not effect the issue.

Comments

mikeytown2’s picture

What are your boost settings? Screenshot of settings page works great for this https://addons.mozilla.org/en-US/firefox/addon/3408
I just tested this and sharing a link with facebook works (boosted & not boosted), so I need more info in order to reproduce this bug.

kmonty’s picture

Attached are the settings.

mikeytown2’s picture

attachments are missing

kmonty’s picture

StatusFileSize
new571.39 KB

Attachment attempt #2

mikeytown2’s picture

Try disabling "Asynchronous Operation: output HTML, close connection, then store static file."

Just a FYI I was able to successfully attach a link via facebook on your site for pages that where cached & not in the boost cache (I added a url query string to the end of an article to make sure I didn't hit the cache).

This might have to do with your ad redirection
transition/inter.php
Does this bug happen 100% of the time?

mikeytown2’s picture

Status: Active » Needs review
StatusFileSize
new904 bytes

doing this on your dev site, I do get the error your describing.

This might have to do with the content-length
Content-Length: 88,021
Html Saved: 88,105 bytes

If this is the cause of the problem, disabling "Asynchronous Operation: output HTML, close connection, then store static file." will let me know. I get this value from strlen(), and according to this note http://php.net/mb-strlen#77040 I shouldn't be using it

try this patch, should fix the content length error

mikeytown2’s picture

Status: Needs review » Fixed

committed

Reopen if this patch doesn't do the trick.

kmonty’s picture

Status: Fixed » Active

Using the latest dev release, I'm still having the same issue. Disabling / enabling Asynchronous does not have an effect. It is presently disabled for testing.

We'll probably launch with cron crawler, which will likely help minimize this bug, but it is still an issue.

mikeytown2’s picture

Version: 6.x-1.16 » 6.x-1.x-dev
Status: Active » Needs review
StatusFileSize
new858 bytes

With "Asynchronous Operation" disabled, boost passes everything through unmodified, the connection is closed when the file has been written. This is something I would get in contact with Facebook about, because I can not think of a good reason why this would not be working; doing a diff of the output, the only difference is the boost tag at the bottom.

That said, I can try a hack to get this working... It will require you to enable "Asynchronous Operation". Try this patch and let me know if it works.

mikeytown2’s picture

Status: Needs review » Fixed

committed and I got 1 report of success #639942: Unboosted pages html-Tag is broken. Once again reopen if this doesn't fix the issue. (I'm fairly aggressive with the issue queue, otherwise this would become unmanageable very quickly)

kmonty’s picture

Status: Fixed » Active

Unfortunately it is still not working. We could hook you up with shell access and an admin account if you are interested in investigating this further.

I'm partly concerned that facebook is timing out the request because of the time it takes boost to generate the page. In general, we've notice there is a significant lag on loading an unboosted page while logged out (whereas there is no lag for logged in / boosted pages).

mikeytown2’s picture

Does it take that long when boost is disabled? What about if you disable politics from getting cached via "Statically cache specific pages:"; does the error still happen? Facebook timing out does make sense.

I'm not at the point yet of needing access to your dev site; thanks for the offer, I'll let you know if I think I need it.

kmonty’s picture

Status: Active » Fixed

Okay, we managed to fix the issue! It actually was not directly related to boost (although it certainly looked like it), but actually a bug with blockcache and the upgrade from 5.x to 6.x, which was causing the 15 second delays before boosting a page (and making facebook time out).

See this post for more info: http://gregorygo.com/2009/07/drupal-5-to-6-upgrade-with-block-cache/

Anyways, Thanks for your help. I hope getting two bug fixes out of it helps make up for the annoyance of a mis-identified issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.