Linux systems website is working - windos system website is not working

K

Knut Krueger

Hi to all
what could be the difference between linux and Winows Client systems.

There is a website (not from me, I am only interested in the difference)
with a lot of forms.
I the client is a Linux system the site (build with php) is working if
it is a windows system the input of text fields will not be stored.
I can only see the html source not the php source.
f.e
.....
<form method="POST" action="acc_domain.php">
<tr>
<td>
<input name="prefix" type="hidden" size="20" readonly value="">
</td>
<td>
<input name="domain" type="text" size="22" readonly value="text
input">
</td>
<td>
<input name="ziel" type="text" size="40" value="other text">
</td>
<td>
<input type="hidden" name="action" value="chgsub">
<input type="image" name="ok" value="true" src="images/edit.gif"
title="Änderung speichern" alt="Änderung speichern">
</td>

</form>
.....



There are some HTML errors (I know they should be fixed, but is not up
to me):

Line 10, Column 29: character "," is not allowed in the value of
attribute "HTTP-EQUIV"

<meta http-equiv="no-cache, must-revalidate, no-store, post-check=0,
pre-chec…

✉

Error Line 10, Column 30: value of attribute "HTTP-EQUIV" must be a
single token

<meta http-equiv="no-cache, must-revalidate, no-store, post-check=0,
pre-chec…

✉

Error Line 10, Column 46: character "," is not allowed in the value of
attribute "HTTP-EQUIV"

…ta http-equiv="no-cache, must-revalidate, no-store, post-check=0,
pre-check=0">

✉

Error Line 10, Column 56: character "," is not allowed in the value of
attribute "HTTP-EQUIV"

…ta http-equiv="no-cache, must-revalidate, no-store, post-check=0,
pre-check=0">

✉

Error Line 10, Column 68: character "=" is not allowed in the value of
attribute "HTTP-EQUIV"

…ta http-equiv="no-cache, must-revalidate, no-store, post-check=0,
pre-check=0">

✉

Error Line 10, Column 81: character "=" is not allowed in the value of
attribute "HTTP-EQUIV"

…ta http-equiv="no-cache, must-revalidate, no-store, post-check=0,
pre-check=0">

✉

Error Line 10, Column 84: required attribute "CONTENT" not specified

…ta http-equiv="no-cache, must-revalidate, no-store, post-check=0,
pre-check=0">

✉

Error Line 121, Column 73: there is no attribute "HEIGHT"

<table border="0" width="100%" cellspacing="5" cellpadding="0"
height="100">

✉

Knut
 
J

Jeff Thies

Hi to all
what could be the difference between linux and Winows Client systems.

There is a website (not from me, I am only interested in the difference)
with a lot of forms.
I the client is a Linux system the site (build with php) is working if
it is a windows system the input of text fields will not be stored.
I can only see the html source not the php source.
f.e
....
<form method="POST" action="acc_domain.php">
<tr>
<td>
<input name="prefix" type="hidden" size="20" readonly value="">
</td>
<td>
<input name="domain" type="text" size="22" readonly value="text input">
</td>
<td>
<input name="ziel" type="text" size="40" value="other text">
</td>
<td>
<input type="hidden" name="action" value="chgsub">
<input type="image" name="ok" value="true" src="images/edit.gif"
title="Änderung speichern" alt="Änderung speichern">
</td>

</form>
....

Client? So this works if the client, not the server, is linux?


There are no errors in the form html that would prevent the server from
doing it's job. I do question the readonly in some of the fields, but
that should only prevent them from being changed.

There are some HTML errors (I know they should be fixed, but is not up
to me):

Line 10, Column 29: character "," is not allowed in the value of
attribute "HTTP-EQUIV"

<meta http-equiv="no-cache, must-revalidate, no-store, post-check=0,
pre-chec…

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That may cause you some problems in IE. Look to see if this works in FF
or another windows UA. I wouldn't think this would cause this problem,
but not knowing what the server is doing, it can't be completely ruled out.

It may be that the php script is doing some work to prevent spam
injection. There may a problem there.

At any rate, if this was all simple and straightforward, there would
be no reason for the script to reject a form coming from a windows box.
Something else is ether going on, or you (or myself) have misinterpreted
the problem.

Jeff
 
J

Jukka K. Korpela

Knut said:
what could be the difference between linux and Winows Client systems.

What makes you think any of the differences matter here?
There is a website (not from me, I am only interested in the
difference) with a lot of forms.

Does it have a URL? Why didn't you post it?
I the client is a Linux system the site (build with php) is working if
it is a windows system the input of text fields will not be stored.

That sentence doesn't really parse. Why don't you specify a URL and the
browsers involved, then describe in simple terms what happens.
I can only see the html source not the php source.

We can't even see the HTML source, just some arbitrary snippets as
potentially munged by your newsreader.
There are some HTML errors (I know they should be fixed, but is not up
to me):

The URL would let us see the errors in context. And if you can't have the
errors fixed, what can you do and why are you asking about the problem
(whatever the problem might be - you didn't really describe it).
<meta http-equiv="no-cache, must-revalidate, no-store, post-check=0,

Clueless technomumbojumbo, but hardly relevant here.
Error Line 121, Column 73: there is no attribute "HEIGHT"

<table border="0" width="100%" cellspacing="5" cellpadding="0"
height="100">

The page relies on quirks mode, but that's a rendering issue.

You haven't given any tangible facts that might be relevant, really.
 
K

Knut Krueger

Am 29.04.2011 18:04, schrieb Jeff Thies:
.....
Client? So this works if the client, not the server, is linux?
Yes this is the strange thing. It is not working with IE Opera and
Firefox on Windows clients, but with Firefox on different Linux clientsKnut
 
K

Knut Krueger

Am 29.04.2011 18:57, schrieb Jukka K. Korpela:
What makes you think any of the differences matter here?


Does it have a URL? Why didn't you post it?

Hi Jukka,

unfortunately not, because it' s behind a login page.


Its a new developed user interface of an ISP. It worked for a long time
during the test period, and suddenly its only working on Linux clients.

I am also not able to see the PHP Source but I am interested what could
be the reason for different behaviour in Linux and Windows.

The html code is exactly the same on Windows Systems and Linux Systems.

As there are some validation errors, my first attempt was that they ma
cause the errors, but it seems that they are not the reasons.

And again, I can use Linux clients to work with, but I never heard that
forms have different behaviour on different clients.

Knut
 
A

Adrienne Boswell

Gazing into my crystal ball I observed Knut Krueger
what could be the difference between linux and Winows Client systems.

There is a website (not from me, I am only interested in the
difference) with a lot of forms.
I the client is a Linux system the site (build with php) is working if
it is a windows system the input of text fields will not be stored.
I can only see the html source not the php source.

A few things:

1. Define working... does the form submit? Is it the php script that is
behaving badly on different systems?

2. Take the full source from both the Linux and Windows page, remove
anything sensitive, and put them up somewhere we can see them. Perhaps
there is some client side browser sniffing going on.

3. Tell the person(s) doing server side that the page is not working,
and again, be specific as to what is not working.
 
K

Knut Krueger

Am 30.04.2011 16:46, schrieb Adrienne Boswell:


As I wrote in the other answers, I have no access to the server, the
code or anything else.
I am only interested why different client operating systems could have
different results with the same HTML code.
Its a user interface of an ISP, which was working well for months. The
ISP told us that he has no idea whats wrong, maybe his programmer has
left him ...
1. Define working... does the form submit? Is it the php script that is
behaving badly on different systems?
From the client side: The values of the text field will not be stored.

Do you really think the server sided PHP script could behave different,
depending on the client operating system?
The Client sided HTML code is absolutely equal on both operating
systems. I realized that, if there are HTML validation errors, the
browsers of Linux and Windows are working different, therefore I was
asking whether the errors could be the problem, but in the other answers
the opinion was that they should not cause the problem.
2. Take the full source
I can only see the HTML code not the PHP code
3. Tell the person(s) doing server side that the page is not working,
and again, be specific as to what is not working.
A lot of customers told him ....
Knut
 
J

Jonathan N. Little

Knut said:
Am 30.04.2011 16:46, schrieb Adrienne Boswell:
A lot of customers told him ....

Well #3 is the only answer. If he doesn't fix it, fire him and hire some
who will|can fix it.
 
J

Jeff Thies

Am 30.04.2011 16:46, schrieb Adrienne Boswell:


As I wrote in the other answers, I have no access to the server, the
code or anything else.
I am only interested why different client operating systems could have
different results with the same HTML code.
Its a user interface of an ISP, which was working well for months. The
ISP told us that he has no idea whats wrong, maybe his programmer has
left him ...

From the client side: The values of the text field will not be stored.

Do you really think the server sided PHP script could behave different,
depending on the client operating system?


This depends on what the php script is doing *if* it is looking for
authentication or credentials. See my other post. Obviously something is
amiss. Sometimes things are too clever by half. That is my guess here,
it is only a guess.

A properly written script shouldn't have these issues. What really is
needed is a look at the php script. If that isn't possible, I suggest
you move the site somewhere that it is possible. Do you have server access?

Are the forms static pages or server generated?

Jeff
 
D

Denis McMahon

what could be the difference between linux and Winows Client systems.
etc ......

1) get hold of a utility called wget.

2) find out the user agent strings for some typical user agents (i.e. web
browsers) running on windows and linux.

3) using wget, request samples of the web page concerned and associated
files (images, javascript, css) with each different user agent string.

4) compare the files you receive to see what the differences between them
is

Rgds

Denis McMahon
 
K

Knut Krueger

Am 30.04.2011 19:16, schrieb Jeff Thies:
On 4/30/2011 11:23 AM, Knut Krueger wrote:

Hi Jeff

I only thing that I would like to understand is, what could be different
on LINUX and Windows when the HTML code is equal. And unfortunately I
have only the client view. But after reading the answers in this tread I
came to the opinion, that there is an error in the PHP script even when
the HTML code is equal on both client systems.
I am afraid this use group is the wrong one to discuss, because it seems
that the problem is not in the generated HTML code.


As the webspace is very customizable it would be a lot of work for me
to move my customers to another webspace. F.e I have more than
customizable 60 PHP values (directory or directory branch based) and can
change the owner from FTP to Apache for each directory or directory
branch. As this user interface is new and self developed there might be
a hard to find error anywhere in the code. And furthermore I have no
other problem with this web space because I can use a Linux client. I
have an own server but I want first to test whether it is hardened
enough against hacking for a longer time ;-)
This depends on what the php script is doing *if* it is looking for
authentication or credentials.

The script is using client based cookies for authentication
A properly written script shouldn't have these issues. What really is
needed is a look at the php script. If that isn't possible, I suggest
you move the site somewhere that it is possible. Do you have server access?

The script is used for changing the document root of domains of a web
space, and is also responsible for creating subdomains

f.e
/var/www/html/
to
/var/www/html/subdir1/ for domain1.com
/var/www/html/subdir2/ for domain2.com

crating subdomains is working
f.e
/var/www/html/subdir1/sudomain1 for
/var/www/html/subdir1/ for subdom.1domain1.com

but trying to change the server path for subdom.1domain1.com is not
working on Windows systems
Are the forms static pages or server generated?
The pages must be server generated as you can see above

Knut
 
J

Jeff Thies

Am 30.04.2011 19:16, schrieb Jeff Thies:

Hi Jeff

I only thing that I would like to understand is, what could be different
on LINUX and Windows when the HTML code is equal. And unfortunately I
have only the client view. But after reading the answers in this tread I
came to the opinion, that there is an error in the PHP script even when
the HTML code is equal on both client systems.
I am afraid this use group is the wrong one to discuss, because it seems
that the problem is not in the generated HTML code.


As the webspace is very customizable it would be a lot of work for me to
move my customers to another webspace. F.e I have more than customizable
60 PHP values (directory or directory branch based) and can change the
owner from FTP to Apache for each directory or directory branch. As this
user interface is new and self developed there might be a hard to find
error anywhere in the code.


Since you wrote this, drop in some tracking code so you can see where
the problem is. This can be as simple as echoing variables or print_r.

If this is too complex for you to step through, consider rewriting it.
Too clever often leads to hidden issues.



And furthermore I have no other problem with
this web space because I can use a Linux client. I have an own server
but I want first to test whether it is hardened enough against hacking
for a longer time ;-)

I don't see how you are going to accomplish that. A hacker may know of
something that you hadn't even considered.
The script is using client based cookies for authentication


All I can say is verify each step, and then see where it is failing.
Speculating on unknowns is a diversion of effort. Simply looking at the
first and last steps only tells that it has failed, not why.

Jeff
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top