Re: [users@httpd] Re: Form problem with non-ascii characters (æ or ß)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 27, 2013 at 7:43 PM, Jim Albert <jim@xxxxxxxxxxxxx> wrote:
On 6/27/2013 11:34 AM, Pi Dizayn wrote:
On Thu, Jun 27, 2013 at 4:57 AM, Jim Albert <jim@xxxxxxxxxxxxx
<mailto:jim@xxxxxxxxxxxxx>> wrote:

    On 6/26/2013 1:02 PM, Pi Dizayn wrote:


             Here is a simple form from that server.

        Sorry I forgot to send the link of the form.
        http://medyab.com/formtest2.php


    Have you checked to see that the browser is submitting the request?
    Check your apache access logs.

    The firefox httpfox addon might help so that you can see the
    communication between browser and server:
    https://addons.mozilla.org/en-us/firefox/addon/httpfox/

    IE has similar feature with F12/Developer tools and the Network tab.

    Maybe viewing the returned headers will help.

    It sure seems related to the character set. Did you check the
    settings on AddDefaultCharset between your old and new apache server
    (possibly in httpd.conf since I assume any .htaccess files would be
    the same)? If that's set, it should match the characters intend to
    display and should be in sync with what you are setting via meta tags.

    I'm assuming that:

    <meta http-equiv='Content-Type' content='text/html; charset=iso-8859-9'>
    is what you set in your code when it was working on your old server.
    Maybe the AddDefaultCharset (assuming it is set) on your new server
    conflicts with iso-8859-9.
    http://httpd.apache.org/docs/current/mod/core.html#adddefaultcharset

    Jim


Dear Jim,

First of all thank you for recommending me HttpFox. I was checking
headers from FireBug but HttpFox looks better.
----------------------------------------------------------------------------------------------------------
There is no log for error or access in httpd logs.
--------------------------------------------------------------------------------------------------------------------
AddDefaultCharset is disabled both of the server.  I tried
"AddDefaultCharset iso-8859-9". It doesn't solve.
----------------------------------------------------------------------------------------------------------
When I checked with HttpFox what I get is;

  * (Request-Line)    POST /formtest2.php HTTP/1.1
  * Host medyab.com <http://medyab.com>
  * User-Agent    Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0)
    Gecko/20100101 Firefox/21.0
  * Accept
    text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  * Accept-Language    en-us,tr;q=0.7,en;q=0.3
  * Accept-Encoding    gzip, deflate
  * Referer http://medyab.com/formtest2.php
  * Cookie

    __utma=256146967.1605253938.1371937614.1372254337.1372331162.12;
    __utmz=256146967.1371937614.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
    __atuvc=7%7C26; PHPSESSID=d2rr0kb8q0rn0hlvt801vt6na5; __utmc=256146967
  * Content-Type    application/x-www-form-urlencoded
  * Content-Length    5


which are the same as the form that works normally on my server.

It also says NS_ERROR_NET_RESET. When I googled NS_ERROR_NET_RESET I saw
that somebody is mentioning about enctype. When I add
enctype="application/x-www-form-urlencoded" to the form, it started
working for Turkish characters and also for æ, ß too. But I can't add
enctype to all of my forms. I feel I'm close to the solution. :)

application/x-www-form-urlencoded should be the default enctype if none is supplied:
http://www.w3schools.com/tags/att_form_enctype.asp

Do you actually see a difference in the "raw" post data with and without setting the enctype? You can see this in httpfox and the encoding type will be indicated.

Are you sure you were not setting an enctype on the form? Check on that especially if you are using some API for form building and not printing out the form html yourself. Maybe some feature in php and it's set to something else.

Since you switched severs maybe something different in the code (eg php) being used to build your forms (assuming you are using a form building API), perhaps something related to:
http://www.w3schools.com/tags/att_form_accept_charset.asp
Did you compare the html source for the forms generated on old and new server?

Taking any form building APIs out of the equation and building the html yourself may provide some clues, but I would expect a comparison between html source for the forms on old and new server to expose any issue there.

Do you still have the old server up and running?
Check the headers *from* the servers when you make the request to load the initial form. Maybe any differences there will offer some clues if it's an Apache config issue.

Just the way it's going, I'm kind of leaning toward something in the form building and perhaps some default php setting differences between old and new server.... again check the html produced between old and new server if possible. So, I'm kind of leaning away from an apache issue here and maybe php... but that's speculation and maybe following some of my thoughts above will point out the needed clues.


Jim

Hi Jim,

I don't think it is a PHP form. This happens in CGI too.

All forms are not generated by PHP. Very simple test forms.

Do you want to test?
  • http://test.pidizayn.com/formtest.php is the form that is on my server which Content-Type is windows-1254 and doesn't have enctype in the form. It works perfect with Turkish characters.
  • http://medyab.com/formtest.php is the form that is on the new server which Content-Type is windows-1254 and doesn't have enctype in the form. It doesn't work with Turkish characters.
  • http://medyab.com/formtest.html is the form that is on the new server which Content-Type is windows-1254 and doesn't have enctype in the form. It doesn't work with Turkish characters.
  • http://medyab.com/formtest2.php is the form that is on the new server which Content-Type is windows-1254 and have enctype="multipart/form-data" in the form. It works perfect with Turkish characters.


--
Boray Eris
www.pidizayn.com

[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux