Hurray,
I've found and fixed the problem!
It turns out that the Ajax reply to a notice (with attachment) says
it's gzipped, but actually isn't on our Hardy server:
HTTP/1.1 200 OK
<snip>
Content-Encoding: gzip
<snip>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en_US" lang="en_US">
<head>
On a server without problems I get this reply to a notice with attachment:
HTTP/1.1 200 OK
<snip>
Content-Encoding: gzip
<snip>
...........UK..&.... ....A~
....Gr..R{.i
Dc.#.
!{....Ic.g+.H.............?.}E....!....
Going through the status.net code I couldn't find a spot where the
content was encoded/deflated whatever, so I started to suspect this
was handled at an other level (php/apache?). It turns out php has a
ini setting: zlib.output_compression which is turned "On" by default
on Hardy. This setting is disabled on my test server that succesfully
completes a notice with attachment. Disabling this setting on the
Hardy server solved the problem.
Enabling zlib.output_compression on my correct testserver produces the
exact same error. We may thus safely conclude that status.net is
incompatible with this php setting (or erroneously relies on something
that isn't correct). Apart from resetting (ini_set()) the setting at
the start of the status.net scripts I would not know how to hack
around or make use of this setting if it was enabled intentionally by
some admin.
Please note that the php ini documentation says the following about
the zlib.output_compression setting though:
; Note: You need to use zlib.output_handler instead of the standard
; output_handler, or otherwise the output will be corrupted.
Maybe that's the solution?
Regards,
Martin
On Fri, Oct 23, 2009 at 16:27, Martin van Es <mrva...@gmail.com> wrote:
> I just discovered that the tinyURL points to the picture 'redirect'
> page correctly, and shows the picture correctly, including the notice.
> So everything seems to have gone correct. The only thing that fails is
> the 'lightbox' overlay if I click in the tinyURL within the notice (it
> comes up, shows a progressbar for a short time and then only a little
> button with an x (close) in it).
>
> The pop-up informing me that something went wrong at upload-time says:
> Sorry! We had trouble sending your notice (0 n/a). Please report the
> problem to the site administrator if this happens again.
>
> This error is at line 217 in js/util.js but obviously something
> unforseen went wrong, because xhr.status is 0 (which is not a valid
> HTTP response code) and xhr.statusText is empty (n/a).
>
> When I change line 269 in actions/newnotice.php to
>
> if ($this->boolean('ajax') && false) {
>
> Effectively making the if clause useless and skipping the ajax
> routine, the posting succeeds without error, but the lightbox in the
> resulting message still fails as described above. Ajax does work
> however when posting a normal message without attachment by the way.
>
> So, right now, I'm out of inspiration where to look next. Anybody any hints?
>
> Regards,
> Martin
>
> On Fri, Oct 23, 2009 at 16:48, Martin van Es <mrva...@gmail.com> wrote:
>> Hi Olof,
>>
>> Thx for sharing your thoughts. The file table isn't missing in the
>> database and actually contains the latest picture I tried to attach.
>> I'll take a look at action/newnotice.php and see what else may go wrong?
>>
>> Regards,
>> Martin!
>>
>> On Fri, Oct 23, 2009 at 15:02, Olof Tjerngren <o...@tjerngren.net> wrote:
>>> Hi Martin,
>>>
>>> I don't think it makes a thumbnail, but the code is in the
>>> action/newnotice.php file.
>>>
>>> It sounds like it could be that the file table is missing in the database,
>>> so you might want to check your DB that there is a file table and that data
>>> is stored there correctly.
>>>
>>> MvH,
>>>
>>> Martin van Es wrote:
>>>>
>>>> Hi Olof,
>>>>
>>>> Commenting out the whole System_Command part in Type.php didn't help
>>>> either.
>>>> I'm quite sure there's no write access problem, because I find the
>>>> uploaded file in the files directory and the attachment has a correct
>>>> tinyURL. As far as I understand the code, at that point we are beyond
>>>> the MIME-type check, otherwise it wouldn't accept the file, would it?
>>>>
>>>> I may be totally wrong, but I have a hunch it may have something to do
>>>> with thumbnailing the picture or other processing that fails on the
>>>> Hardy system somewhere?
>>>> Could you or anyone point me to the place where the processing (if
>>>> any?) happens after the uploading or tinURL creation?
>>>>
>>>> Regards,
>>>> Martin
>>>>
>>>> On Fri, Oct 23, 2009 at 10:30, Olof Tjerngren <o...@tjerngren.net> wrote:
>>>>
>>>>>
>>>>> Sorry I couldn't help, I've only had problems with write access to the
>>>>> file
>>>>> directory and mime decoding.
>>>>>
>>>>> I'll fill in some detail in case anyone else runs in to my mime issues.
>>>>> For Solaris the issue was that it fell back to the file command that
>>>>> isn't
>>>>> the same as the Linux version of file. It will not give you the mime type
>>>>> only. I made a simple php mime translator for the types of file that was
>>>>> supported.
>>>>> On OpenSuSE it simply died when it came to running the pear
>>>>> System_Command
>>>>> call, no error, nothing in the logfile. I simply commented out that part
>>>>> in
>>>>> the Type.php file, MIME_Type_Extension seems to work so far...
>>>>>
>>>>> I guess it's running the file command that tripped me up in both cases.
>>>>> :)
>>>>>
>>>>> MvH,
>>>>>
>>>>> Martin van Es wrote:
>>>>>
>>>>>>
>>>>>> Thx for the tip, but that didn't help. If I test status.net on my
>>>>>> Jaunty system, attachments work like a charm and there's no fileinfo
>>>>>> module installed. I see in the code now that there are several
>>>>>> fallback mechanisms to find out the mimi-type.
>>>>>>
>>>>>> Grz
>>>>>> Martin
>>>>>>
>>>>>> On Thu, Oct 22, 2009 at 23:47, Olof Tjerngren <o...@tjerngren.net>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> I've had that issues on two different servers, in both cases it was
>>>>>>> mime
>>>>>>> type detection that failed.
>>>>>>> It seems to work best if the fileinfo php module is installed, so it's
>>>>>>> probably worth to give that a try first.
>>>>>>>
>>>>>>> MvH,
>>>>>>>
>>>>>>> Martin van Es wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> I've had exactly the same problem and in contrary to what the
>>>>>>>> documentation says I pinned it down to my PHP version being too old.
>>>>>>>> My problems were caused by the PHP version in Ubuntu Hardy if that
>>>>>>>> helps.
>>>>>>>>
>>>>>>>> I've also offered to see if I could hack around the problem if I knew
>>>>>>>> where to look, but the community doesn't seem too eager for help on
>>>>>>>> this problem...
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On Wed, Oct 14, 2009 at 17:36, David Peterson <dpeters...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm running the latest version of StatusNet, 0.8.1, and running into
>>>>>>>>> two
>>>>>>>>> issues with attachments. The first issue is that when I try to post I
>>>>>>>>> get
>>>>>>>>> the following pop-up error message "Sorry! We had trouble sending
>>>>>>>>> your
>>>>>>>>> notice (0 n/a). Please report the problem to the site administrator
>>>>>>>>> if
>>>>>>>>> this
>>>>>>>>> happens again." When I click ok and go to the home page the post is
>>>>>>>>> there
>>>>>>>>> and the attachment was uploaded successfully. However, when I click
>>>>>>>>> on
>>>>>>>>> the
>>>>>>>>> tiny url the pop-up lightbox tries to appear and then disappears
>>>>>>>>> leaving
>>>>>>>>> an
>>>>>>>>> "X" and fails to open. If I right click on the attachment url and
>>>>>>>>> open
>>>>>>>>> it
>>>>>>>>> in
>>>>>>>>> a new tab it appears and I can view it. There is nothing in the log
>>>>>>>>> files
>>>>>>>>> that give an clues and I know it's not a client side issue as I can
>>>>>>>>> open
>>>>>>>>> up
>>>>>>>>> attachments on the http://identi.ca/ site. Any ideas? You can try it
>>>>>>>>> out
>>>>>>>>> by
>>>>>>>>> going to http://dev.fusebit.com and clicking the first couple of
>>>>>>>>> posts.
>>>>>>>>>
>>>>>>>>> The following libraries are installed on my server running CentOS
>>>>>>>>> 5.3.
>>>>>>>>> I'm
>>>>>>>>> also using lighttpd-1.4.22 for the web server.
>>>>>>>>>
>>>>>>>>> gettext
>>>>>>>>> PEAR
>>>>>>>>> DB
>>>>>>>>> DB_DataObject
>>>>>>>>> Console_Getopt
>>>>>>>>> Facebook API
>>>>>>>>> HTTP_Request
>>>>>>>>> Mail
>>>>>>>>> Mail_mimeDecode
>>>>>>>>> Mime_Type
>>>>>>>>> Net_URL_Mapper
>>>>>>>>> Net_Socket
>>>>>>>>> Net_SMTP
>>>>>>>>> Net_URL
>>>>>>>>> Net_URL2
>>>>>>>>> Services_oEmbed
>>>>>>>>> System_Command
>>>>>>>>> XMPPHP
>>>>>>>>> PHP Markdown
>>>>>>>>> OAuth
>>>>>>>>> Validate
>>>>>>>>>
>>>>>>>>> -- Dave
>>>>>>>>> _______________________________________________
>>>>>>>>> StatusNet-dev mailing list
>>>>>>>>> StatusNet-dev@lists.status.net
>>>>>>>>> http://lists.status.net/mailman/listinfo/statusnet-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> if but was of any use, it would be a logic operator
>>
>
>
>
> --
> if but was of any use, it would be a logic operator
>
--
if but was of any use, it would be a logic operator
_______________________________________________
StatusNet-dev mailing list
StatusNet-dev@lists.status.net
http://lists.status.net/mailman/listinfo/statusnet-dev
