Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Bricolage: users

Virtual FTP transfer fails on certain templates

 

 

Bricolage users RSS feed   Index | Next | Previous | View Threaded


bryancarney at gmail

Jul 16, 2013, 2:13 PM

Post #1 of 8 (169 views)
Permalink
Virtual FTP transfer fails on certain templates

Might anyone know what the cause of transfer failures would be via the
virtual ftp for bricolage?

It is certain specific templates files that fail and then close the FTP
connection attempt after failing.

I have tried ensuring the templates are checked in and in current /
deployed version

It will consistently happen on certain files only, from multiple clients
and IP addresses / setups.

Here is the output from an ftp client (filezilla):

Command: CWD /IFEX/Utilities/util

Response: 250 Changed directory OK.

Command: TYPE I

Response: 200 TYPE changed to I.

Command: PASV

Response: 227 Entering Passive Mode (208,70,244,162,254,92)

Command: RETR render_html_ifex_daily.mc

Response: 150 Opening BINARY mode data connection for file
render_html_ifex_daily.mc.

Error: Connection closed by server

Error: File transfer failed


Here is a successful transfer:


Command: CWD /IFEX/Utilities/util

Response: 250 Changed directory OK.

Command: TYPE I

Response: 200 TYPE changed to I.

Command: PASV

Response: 227 Entering Passive Mode (208,70,244,162,228,173)

Command: RETR render_headline.mc

Response: 150 Opening BINARY mode data connection for file
render_headline.mc.

Response: 226 File retrieval complete. Data connection has been closed.

Status: File transfer successful, transferred 2,439 bytes in 1 second


bryan at bryancarney

Jul 16, 2013, 2:12 PM

Post #2 of 8 (164 views)
Permalink
Virtual FTP transfer fails on certain templates [In reply to]

Might anyone know what the cause of transfer failures would be via the
virtual ftp for bricolage?

It is certain specific templates files that fail and then close the FTP
connection attempt after failing.

I have tried ensuring the templates are checked in and in current /
deployed version

It will consistently happen on certain files only, from multiple clients
and IP addresses / setups.

Here is the output from an ftp client (filezilla):

Command: CWD /IFEX/Utilities/util

Response: 250 Changed directory OK.

Command: TYPE I

Response: 200 TYPE changed to I.

Command: PASV

Response: 227 Entering Passive Mode (208,70,244,162,254,92)

Command: RETR render_html_ifex_daily.mc

Response: 150 Opening BINARY mode data connection for file
render_html_ifex_daily.mc.

Error: Connection closed by server

Error: File transfer failed


Here is a successful transfer:


Command: CWD /IFEX/Utilities/util

Response: 250 Changed directory OK.

Command: TYPE I

Response: 200 TYPE changed to I.

Command: PASV

Response: 227 Entering Passive Mode (208,70,244,162,228,173)

Command: RETR render_headline.mc

Response: 150 Opening BINARY mode data connection for file
render_headline.mc.

Response: 226 File retrieval complete. Data connection has been closed.

Status: File transfer successful, transferred 2,439 bytes in 1 second


ps at phillipadsmith

Jul 16, 2013, 2:49 PM

Post #3 of 8 (161 views)
Permalink
Re: Virtual FTP transfer fails on certain templates [In reply to]

Search for those pesky characters that MS Word inserts: m-dashes, smart quotes, and so on. I found that if those are in a template, not properly encoded, they will cause the VirtualFTP to fail like that.

Phillip.

On 2013-07-16, at 4:13 PM, Bryan Carney <bryancarney [at] gmail> wrote:

> Might anyone know what the cause of transfer failures would be via the
> virtual ftp for bricolage?
>
> It is certain specific templates files that fail and then close the FTP
> connection attempt after failing.
>
> I have tried ensuring the templates are checked in and in current /
> deployed version
>
> It will consistently happen on certain files only, from multiple clients
> and IP addresses / setups.
>
> Here is the output from an ftp client (filezilla):
>
> Command: CWD /IFEX/Utilities/util
>
> Response: 250 Changed directory OK.
>
> Command: TYPE I
>
> Response: 200 TYPE changed to I.
>
> Command: PASV
>
> Response: 227 Entering Passive Mode (208,70,244,162,254,92)
>
> Command: RETR render_html_ifex_daily.mc
>
> Response: 150 Opening BINARY mode data connection for file
> render_html_ifex_daily.mc.
>
> Error: Connection closed by server
>
> Error: File transfer failed
>
>
> Here is a successful transfer:
>
>
> Command: CWD /IFEX/Utilities/util
>
> Response: 250 Changed directory OK.
>
> Command: TYPE I
>
> Response: 200 TYPE changed to I.
>
> Command: PASV
>
> Response: 227 Entering Passive Mode (208,70,244,162,228,173)
>
> Command: RETR render_headline.mc
>
> Response: 150 Opening BINARY mode data connection for file
> render_headline.mc.
>
> Response: 226 File retrieval complete. Data connection has been closed.
>
> Status: File transfer successful, transferred 2,439 bytes in 1 second

--
Phillip Smith
http://phillipadsmith.com


david at kineticode

Jul 17, 2013, 3:17 AM

Post #4 of 8 (160 views)
Permalink
Re: Virtual FTP transfer fails on certain templates [In reply to]

On Jul 16, 2013, at 11:49 PM, Phillip Smith <ps [at] phillipadsmith> wrote:

> Search for those pesky characters that MS Word inserts: m-dashes, smart quotes, and so on. I found that if those are in a template, not properly encoded, they will cause the VirtualFTP to fail like that.

If so, it’s either a bug, or there needs to be a better way to emit the relevant error message.

Best,

David


AWilson at RFXTechnologies

Jul 17, 2013, 7:20 AM

Post #5 of 8 (160 views)
Permalink
RE: Virtual FTP transfer fails on certain templates [In reply to]

I can confirm that having those stupid MSWORD inserts will break the VirtualFTP.
I had a template that was always failing until this morning, when I found the offending apostrophe that was a closing single quote and changed it.

Adam

-----Original Message-----
From: users [at] lists [mailto:users [at] lists] On Behalf Of David E. Wheeler
Sent: Wednesday, July 17, 2013 6:17 AM
To: users [at] lists
Subject: Re: Virtual FTP transfer fails on certain templates

On Jul 16, 2013, at 11:49 PM, Phillip Smith <ps [at] phillipadsmith> wrote:

> Search for those pesky characters that MS Word inserts: m-dashes, smart quotes, and so on. I found that if those are in a template, not properly encoded, they will cause the VirtualFTP to fail like that.

If so, it's either a bug, or there needs to be a better way to emit the relevant error message.

Best,

David


bryan at bryancarney

Jul 17, 2013, 8:38 AM

Post #6 of 8 (160 views)
Permalink
Re: Virtual FTP transfer fails on certain templates [In reply to]

Yayy thanks all --

I hunted and used a few scripts before this one seemed to work:

http://www.nousphere.net/cleanspecial.php

I'll do a diff before & after and see if I can find the offending
characters -- I had already tried smart quote replacement.


On Wed, Jul 17, 2013 at 10:20 AM, Adam Wilson
<AWilson [at] rfxtechnologies>wrote:

> I can confirm that having those stupid MSWORD inserts will break the
> VirtualFTP.
> I had a template that was always failing until this morning, when I found
> the offending apostrophe that was a closing single quote and changed it.
>
> Adam
>
> -----Original Message-----
> From: users [at] lists [mailto:users [at] lists]
> On Behalf Of David E. Wheeler
> Sent: Wednesday, July 17, 2013 6:17 AM
> To: users [at] lists
> Subject: Re: Virtual FTP transfer fails on certain templates
>
> On Jul 16, 2013, at 11:49 PM, Phillip Smith <ps [at] phillipadsmith> wrote:
>
> > Search for those pesky characters that MS Word inserts: m-dashes, smart
> quotes, and so on. I found that if those are in a template, not properly
> encoded, they will cause the VirtualFTP to fail like that.
>
> If so, it's either a bug, or there needs to be a better way to emit the
> relevant error message.
>
> Best,
>
> David
>
>


bryancarney at gmail

Jul 17, 2013, 8:38 AM

Post #7 of 8 (160 views)
Permalink
Re: Virtual FTP transfer fails on certain templates [In reply to]

Yayy thanks all --

I hunted and used a few scripts before this one seemed to work:

http://www.nousphere.net/cleanspecial.php

I'll do a diff before & after and see if I can find the offending
characters -- I had already tried smart quote replacement.


On Wed, Jul 17, 2013 at 10:20 AM, Adam Wilson
<AWilson [at] rfxtechnologies>wrote:

> I can confirm that having those stupid MSWORD inserts will break the
> VirtualFTP.
> I had a template that was always failing until this morning, when I found
> the offending apostrophe that was a closing single quote and changed it.
>
> Adam
>
> -----Original Message-----
> From: users [at] lists [mailto:users [at] lists]
> On Behalf Of David E. Wheeler
> Sent: Wednesday, July 17, 2013 6:17 AM
> To: users [at] lists
> Subject: Re: Virtual FTP transfer fails on certain templates
>
> On Jul 16, 2013, at 11:49 PM, Phillip Smith <ps [at] phillipadsmith> wrote:
>
> > Search for those pesky characters that MS Word inserts: m-dashes, smart
> quotes, and so on. I found that if those are in a template, not properly
> encoded, they will cause the VirtualFTP to fail like that.
>
> If so, it's either a bug, or there needs to be a better way to emit the
> relevant error message.
>
> Best,
>
> David
>
>


david at kineticode

Jul 17, 2013, 8:47 AM

Post #8 of 8 (160 views)
Permalink
Re: Virtual FTP transfer fails on certain templates [In reply to]

On Jul 17, 2013, at 5:38 PM, Bryan Carney <bryancarney [at] gmail> wrote:

> Yayy thanks all --
>
> I hunted and used a few scripts before this one seemed to work:
>
> http://www.nousphere.net/cleanspecial.php
>
> I'll do a diff before & after and see if I can find the offending
> characters -- I had already tried smart quote replacement.

You can also use Encode::ZapCP1252::fix_cp1252() to change CP1252 characters to UTF-8.

https://metacpan.org/module/Encode::ZapCP1252

Best,

David

Bricolage users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.