[fw-general] Found the issue to Firefox - double request !
Finally, I've found the error in my case : Commenting the HTML line below stops the double request : meta http-equiv=Content-Type content=text/html; charset=utf-8 However I don't know how to fix it ... I've been using that meta for ages, never had a problem. Seems that for that specific request it causes problems. I need to specify that the page is UTF-8 in any case. Any idea ? -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/Firefox-double-request-tp2992431p2995111.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Zend_Mail (encoding) problem?
Hello Everybody,
I have run into two strange problems using Zend_Mail (UTF-8) over SMTP
transport. Both look like obvious bugs which seems quite unlikely...
--- First one:
$mail = new Zend_Mail('UTF-8');
$mail-setBodyText(Příliš žluťoučký kůň úpěl ďábelské ódy);
The above email is received like this:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
P=3DC5=3D99=3DC3=3DADli=3DC5=3DA1 =3DC5=3DBElu=3DC5=3DA5ou=3DC4=3D8Dk=3D=
C3=3DBD k=3DC5=3DAF=3DC5=3D88 =3DC3=3DBA=3D=0Ap=3DC4=3D9Bl =3DC4=3D8F=3D=
C3=3DA1belsk=3DC3=3DA9 =3DC3=3DB3dy
Where the header is defined correctly (utf-8, quoted printable), but the
body don't seem to be. First, it's slightly different as with using php
native 'quoted_printable_encode', which I would not consider as a problem by
itself (different line width/eol settings possibly?), but also gmail thinks
it's not ok, as I can't read it in gmail...
Is this a Zend_Mime::encodeQuotedPrintable bug?
--- Second one (explicitly define body as base64):
$mail = new Zend_Mail('UTF-8');
$mail-setBodyText(Příliš žluťoučký kůň úpěl ďábelské ódy, null,
Zend_Mime::ENCODING_BASE64);
This one is received like this:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
UMWZw61sacWhIMW+bHXFpW91xI1rw70ga8WvxYggw7pwxJtsIMSPw6FiZWxza8OpIMOzZHk=
=3D
Where the header is wrong (defined as quoted-printable instead of expected
base64). The content seems to be encoded ok, but as it is defined as
quoted-printable I can't read it again.
Any light in the dark would be highly appreciated, thanks in advance!
M.
[fw-general] Letter case problem in Zend_Http_Response
I have read the Zend_Http_Response: http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Http/Response.php The headers were constructed using... $this-headers[ucwords(strtolower($name))] = $value; So only 1st character will be upper case, others will be lower case. Is it part of a standard? If yes, any document/reference/link? Thanks.
Re: [fw-general] Letter case problem in Zend_Http_Response
this should help: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 Each header field consists of a name followed by a colon (:) and the field value. Field names are case-insensitive. Am 14.10.2010 18:05, schrieb Ryan Chan: I have read the Zend_Http_Response: http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Http/Response.php The headers were constructed using... $this-headers[ucwords(strtolower($name))] = $value; So only 1st character will be upper case, others will be lower case. Is it part of a standard? If yes, any document/reference/link? Thanks.
Re: [fw-general] Letter case problem in Zend_Http_Response
Hi, On Fri, Oct 15, 2010 at 12:32 AM, Artem Stepin aste...@24h.de wrote: this should help: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 Each header field consists of a name followed by a colon (:) and the field value. Field names are case-insensitive. So I just wonder why only 1st letter is uppercase.
Re: [fw-general] Letter case problem in Zend_Http_Response
As brought up by Artem, it's case-insensitive so it shouldn't matter as long as browsers are following the spec. -- *Hector Virgen* Sr. Web Developer Walt Disney Parks and Resorts Online http://www.virgentech.com On Thu, Oct 14, 2010 at 9:47 AM, Ryan Chan ryanchan...@gmail.com wrote: Hi, On Fri, Oct 15, 2010 at 12:32 AM, Artem Stepin aste...@24h.de wrote: this should help: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 Each header field consists of a name followed by a colon (:) and the field value. Field names are case-insensitive. So I just wonder why only 1st letter is uppercase.
Re: [fw-general] Letter case problem in Zend_Http_Response
-- Ryan Chan ryanchan...@gmail.com wrote (on Friday, 15 October 2010, 12:47 AM +0800): On Fri, Oct 15, 2010 at 12:32 AM, Artem Stepin aste...@24h.de wrote: this should help: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 Each header field consists of a name followed by a colon (:) and the field value. Field names are case-insensitive. So I just wonder why only 1st letter is uppercase. I think this may be due to how PHP handles header names, particularly the Location header. However, I'm not 100% positive; hopefully Shahar (author of the component) will jump in to respond. Is this actually causing some functionality issues for you? Or are you just curious about why it's coded the way it is? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
[fw-general] Zend Framework 1.11.0 BETA 1 Released
Zend Framework 1.11.0BETA1 Released The Zend Framework team is pleased to announce the immediate availability of the first beta release of Zend Framework 1.11.0. This release is the culmination of several months of effort by contributors and Zend Framework partners, and offers several key new features, including support for mobile devices and the first stable release of the SimpleCloud API. You may download the release from the following location: http://framework.zend.com/download/latest (Note, beta releases appear separate from stable releases.) This release is of BETA quality, and should be used for testing purposes only, not production. While the code has been well tested, we do expect there may be a few issues to resolve prior to a release candidate or general access release. New Features in Zend Framework 1.11 === Mobile Support -- Zend Framework 1.11 marks the first release with explicit support for mobile devices, via the new component Zend_Http_UserAgent. This component was developed by Raphael Carles. Carles is CTO of Interakting, the digital agency of Business Decision Group of France. Interakting employs 150 PHP professionals to build industrial PHP projects, and its clients include Canal +/Vivendi, BNP Paribas, Samsung France, Ministry of Education, Alapage (Orange), Orange Tunisia, and many others. As such, they have extensive experience in supporting mobile devices, and stepped forward to contribute to Zend Framework, which they leverage in their projects. Zend_Http_UserAgent performs two responsibilities: • User-Agent detection • Device capabilities detection, based on User-Agent The component includes a features adapter mechanism that allows developers to tie into different backends for the purpose of discovering device capabilities. Currently, the only shipped adapter is for the WURFL (Wireless Universal Resource File) API. Luca Passani, author and lead of the WURFL project, has provided an exemption to Zend Framework to provide a non-GPL adapter accessing the WURFL PHP API. Additional hooks into the component are provided via a Zend_Application resource plugin, and a Zend_View helper, allowing developers the ability to return output customized for the detected device (e.g., alternate layouts, alternate images, Flash versus HTML5 support, etc.). Zend_Cloud: SimpleCloud API --- During ZendCon 2009, Zend announced a prototype of the SimpleCloud API. This API was to provide hooks into cloud-based document storage, queue services, and file storage. Zend Framework 1.11.0 markes the first official, stable release of Zend_Cloud, Zend Framework's PHP version of the SimpleCloud API. Current support includes: • Document Services: □ Amazon SimpleDB □ Windows Azure's Table Storage • Queue Services: □ Amazon Simple Queue Service (SQS) □ Windows Azure's Queue Service □ All adapters supported by Zend_Queue: ☆ Zend Platform JobQueue ☆ Memcacheq ☆ Relational Database ☆ ActiveMQ • Storage Services: □ Amazon Simple Storage Service (S3) □ Windows Azure's Blog Storage □ Nirvanix □ Local filesystem When using any of the SimpleCloud APIs, your code will be portable across the various adapters provided, allowing you to pick and choose your services, as well as try different services until you find one that suits your application or business needs. Additionally, if you find you need to code adapter-specific features, you can drop down to the specific adapter in order to do so. More adapters will be arriving in the coming months, giving you even more options! We thank Wil Sinclair and Stas Malyshev for their assistance in the initial releases of Zend_Cloud. Security Several classes in Zend Framework were patched to eliminate the potential for leaking timing information from the direct comparison of sensitive data such as plaintext passwords or cryptographic signatures to user input. These leaks arise from the normal process of comparing any two strings in PHP. The nature of the leaks is that strings are often compared byte by byte, with a negative result being returned early as soon as any set of non-matching bytes is detected. The more bytes that are equal (starting from the first byte) between both sides of the comparison, the longer it takes for a final result to be returned. Based on the time it takes to return a negative or positive result, it is possible that an attacker could, over many samples of requests, craft a string that compares positively to another secret string value known only to a target server simply by guessing the string one byte at a time and measuring each guess' execution time. This server secret could be a plaintext password or the correct cryptographic signature of a request the attacker wants to execute, such as is used in several open protocols including OpenID and OAuth. This
[fw-general] Lazy Loading Resources
Hi All, I've been doing some research on lazy loading resources in Zend Framework, and it seems that the decision has been made that resources that should be lazy loaded should not be a part of the bootstrapping mechanism. I'm not sure that I agree with this idea, so I'd like to re-open the discussion. For example, I currently have code which makes use of Zend_Service_LiveDocx. For Dependency Injection, I would rather the class be configured outside of the methods that are calling it, so creating a resource seems to be the best bet. However, it's a waste of time to initialize the LiveDocx class 99% of the time, since only a small portion of the application uses it. In this particular case I believe the overhead will be very minimal compared to the added complexity/duplication of doing it any other way, but that's not necessarily true in other cases. Being that resources are able to load their dependencies themselves using the Boostrap mechanism, wouldn't it make more sense to lazy load ALL resources by default? Of course this becomes an issue when you're using _init functions in your Bootstrap class to configure the application, and they don't return any resources. So, it seems that there needs to be some distinction between initialization and resources. Or, perhaps, a distinction between resource classes, and init functions within the Boostrap file. Thoughts? -- A.J. Brown Software Engineer, ZCE blog : http://ajbrown.org talk : (937) 540-0099 chat : IntypicaAJ
SV: [fw-general] Found the issue to Firefox - double request !
Just a thought; What charset is your webserver set to send? If it's not UTF-8, you might want to change that and the problem is likely to go away. Mvh Danny -Ursprungligt meddelande- Från: debussy007 [mailto:debussy...@gmail.com] Skickat: den 14 oktober 2010 12:06 Till: fw-general@lists.zend.com Ämne: [fw-general] Found the issue to Firefox - double request ! Finally, I've found the error in my case : Commenting the HTML line below stops the double request : meta http-equiv=Content-Type content=text/html; charset=utf-8 However I don't know how to fix it ... I've been using that meta for ages, never had a problem. Seems that for that specific request it causes problems. I need to specify that the page is UTF-8 in any case. Any idea ? -- View this message in context: http://zend-framework- community.634137.n4.nabble.com/Firefox-double-request- tp2992431p2995111.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Lazy Loading Resources
I agree with yo 100%. Not being able to lazy load resources doesn't make sense. There are very few resources that are required with every page load. Even the DB or View objects may not be necessary much of the time with proper caching. I created my own resource manager that creates resources only when they are requested and this handles all of my resources. I still use a bootstrap class but it requests all resources from the resource manager. Mark On Thu, Oct 14, 2010 at 3:09 PM, A.J. Brown a...@ajbrown.org wrote: Hi All, I've been doing some research on lazy loading resources in Zend Framework, and it seems that the decision has been made that resources that should be lazy loaded should not be a part of the bootstrapping mechanism. I'm not sure that I agree with this idea, so I'd like to re-open the discussion. For example, I currently have code which makes use of Zend_Service_LiveDocx. For Dependency Injection, I would rather the class be configured outside of the methods that are calling it, so creating a resource seems to be the best bet. However, it's a waste of time to initialize the LiveDocx class 99% of the time, since only a small portion of the application uses it. In this particular case I believe the overhead will be very minimal compared to the added complexity/duplication of doing it any other way, but that's not necessarily true in other cases. Being that resources are able to load their dependencies themselves using the Boostrap mechanism, wouldn't it make more sense to lazy load ALL resources by default? Of course this becomes an issue when you're using _init functions in your Bootstrap class to configure the application, and they don't return any resources. So, it seems that there needs to be some distinction between initialization and resources. Or, perhaps, a distinction between resource classes, and init functions within the Boostrap file. Thoughts? -- A.J. Brown Software Engineer, ZCE blog : http://ajbrown.org talk : (937) 540-0099 chat : IntypicaAJ -- Have fun or die trying - but try not to actually die.
[fw-general] Re: Zend_Mail (encoding) problem?
Quick update: surprisingly, I found a bug on my end.
For anyone interested: I was getting and manipulating body text (via
$mail-getBodyText(true)) which I didn't realized was already encoded. So it
ended up being encoded twice.
Cheers,
m.
On Thu, Oct 14, 2010 at 5:12 PM, Marian Meres marian.me...@gmail.comwrote:
Hello Everybody,
I have run into two strange problems using Zend_Mail (UTF-8) over SMTP
transport. Both look like obvious bugs which seems quite unlikely...
--- First one:
$mail = new Zend_Mail('UTF-8');
$mail-setBodyText(Příliš žluťoučký kůň úpěl ďábelské ódy);
The above email is received like this:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
P=3DC5=3D99=3DC3=3DADli=3DC5=3DA1
=3DC5=3DBElu=3DC5=3DA5ou=3DC4=3D8Dk=3D=
C3=3DBD k=3DC5=3DAF=3DC5=3D88 =3DC3=3DBA=3D=0Ap=3DC4=3D9Bl
=3DC4=3D8F=3D=
C3=3DA1belsk=3DC3=3DA9 =3DC3=3DB3dy
Where the header is defined correctly (utf-8, quoted printable), but the
body don't seem to be. First, it's slightly different as with using php
native 'quoted_printable_encode', which I would not consider as a problem by
itself (different line width/eol settings possibly?), but also gmail thinks
it's not ok, as I can't read it in gmail...
Is this a Zend_Mime::encodeQuotedPrintable bug?
--- Second one (explicitly define body as base64):
$mail = new Zend_Mail('UTF-8');
$mail-setBodyText(Příliš žluťoučký kůň úpěl ďábelské ódy, null,
Zend_Mime::ENCODING_BASE64);
This one is received like this:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
UMWZw61sacWhIMW+bHXFpW91xI1rw70ga8WvxYggw7pwxJtsIMSPw6FiZWxza8OpIMOzZHk=
=3D
Where the header is wrong (defined as quoted-printable instead of
expected base64). The content seems to be encoded ok, but as it is defined
as quoted-printable I can't read it again.
Any light in the dark would be highly appreciated, thanks in advance!
M.
