httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pi Dizayn <pidiz...@gmail.com>
Subject Re: [users@httpd] Re: Form problem with non-ascii characters (æ or ß)
Date Fri, 28 Jun 2013 15:46:59 GMT
On Thu, Jun 27, 2013 at 7:43 PM, Jim Albert <jim@netrition.com> wrote:

> On 6/27/2013 11:34 AM, Pi Dizayn wrote:
>
>> On Thu, Jun 27, 2013 at 4:57 AM, Jim Albert <jim@netrition.com
>> <mailto:jim@netrition.com>> 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<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/<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<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<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<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<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

Mime
View raw message