How do I get HTML sent to server?

[MC]

Hey,

I have a need to get HTML from a client back to a server to do server
processing. I would like the HTML and form data both. Is there a simple way
to capture that? I do not want to submit the page...I will use ajax to send
the data.

I know how to get the elements but not the entire page or form. I am really
just interested in specifying document.form2 and sending that.

Thanks,
Mica

 

[SAM]

MC a écrit :

Hey,

I have a need to get HTML from a client back to a server to do server
processing. I would like the HTML and form data both. Is there a simple way
to capture that? I do not want to submit the page...I will use ajax to send
the data.

I know how to get the elements but not the entire page or form. I am really
just interested in specifying document.form2 and sending that.

I do not understand why you need the html ...
Simplest being to submit the form2 using Ajax, then on response, to
populate the fields (or to replace the whole content of form2).

 

[MC]

MC a écrit :

I do not understand why you need the html ...
Simplest being to submit the form2 using Ajax, then on response, to
populate the fields (or to replace the whole content of form2).

Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

 

[Jonas Raoni]

Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

Strange. If you want the *exactly* HTML sent back to your server, you
should not use "innerHTML" (the browser may output it the way it wants),
instead store (at server-side time) a copy of the HTML that must be sent
back somewhere (hidden input, JavaScript variable, [...]) and when sending
your form, grab that content.

 

[MC]

Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

Strange. If you want the *exactly* HTML sent back to your server, you
should not use "innerHTML" (the browser may output it the way it wants),
instead store (at server-side time) a copy of the HTML that must be sent
back somewhere (hidden input, JavaScript variable, [...]) and when sending
your form, grab that content.

Ok, again, the library wants the entire content to process. It will make an
archive of the page the way the client sees it with their form data added.
Does anyone know how to do this?

MC

Mica

 

[Evertjan.]

MC wrote on 16 jun 2008 in comp.lang.javascript:

Ok, again, the library wants the entire content to process. It will
make an archive of the page the way the client sees it with their form
data added. Does anyone know how to do this?

Who is the boss, you the programmer or the library?
If you do not like a library function, write your own alternative one.

 

[SAM]

Evertjan. a écrit :

MC wrote on 16 jun 2008 in comp.lang.javascript:


Who is the boss, you the programmer or the library?
If you do not like a library function, write your own alternative one.

True but :
that doesn't explain to me how it is possible to submit the html ... ?!
(I thought it needs ftp)

What I do not understand : certainly somebody or something did create
the html, so it is most than probable that the html file must exist
somewhere (or can be saved somewhere).

 

[Evertjan.]

SAM wrote on 16 jun 2008 in comp.lang.javascript:

Evertjan. a écrit :

True but :
that doesn't explain to me how it is possible to submit the html ...
?! (I thought it needs ftp)

You can send any string to the server using form post.
HTML is just a text string.

What I do not understand : certainly somebody or something did create
the html, so it is most than probable that the html file must exist
somewhere (or can be saved somewhere).

If you mean the html of a web page, that either exists on the server as
a file or is made on the spot by serverside script. And the received
html is probably stored in the client browser cashe, but that file is
not available to clientside script, only through the browser's
view-source menu, or you can search for it by hand on your computer.

So why not "get" it from the server using xmlhttp. You can even, with
serverside scripting, have called by the server any page on the web, so
also pages on the own server, without involving the client, other than
that the clinet initiates that script.

If, however, you mean "the html" on the client browser [posweebly after
the client has manipulated it by inserting strings, or by clientside
script], that does not exist, as the visualisation is stored in the DOM
tree, a kind of relational database, and if you call innerHTML of the
body, a new and certainly different html is [re]constructed from the DOM
tree, and most of the <head> part is usually not reconstructed.

===========

Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

 

[SAM]

Evertjan. a écrit :

SAM wrote on 16 jun 2008 in comp.lang.javascript:

Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

Thanks for the given light, but I'm not the OP

 

[Evertjan.]

SAM wrote on 16 jun 2008 in comp.lang.javascript:

Evertjan. a écrit :

Thanks for the given light, but I'm not the OP

Oh, sorry.

 

[MC]

Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

Evertjan,

This is not an illogical slavery. The library is GREAT. Everybody is hung up
on why I want to do this and not the how.
DOES ANYONE KNOW HOW???

The why, is I want to construct an archival image of the view a user sees in
a client browser. This library can be used to construct an encrypted page
view image while maintaining inner data and it is easily renderable while
encrypted by most browsers. The archival image will be used as a legal
construct to document what a user saw in the browser and may be used in
court. Web sites do not come from a single server so reconstructing what the
server serves is inappropriate as the client view may get content from
dozens of servers to build a single client view.

MC

 

[Lasse Reichstein Nielsen]

Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

Sending the HTML won't give you that. It only gives you the structure
of the HTML, not what it *looks* like when displayed in a browser.
For that, you need a screenshot.

If you insist on converting the page's document structure back to HTML
and send that back to the server (including user-entered values in
form controls), you'll have to traverse the DOM structure and build
the HTML.

The non-standard innerHTML property only reads the original value
of input controls (i.e., "inputControl.originalValue", not the currently
entered value, "inputControl.value"). I.e., it misses the user entered
values.

This means that the HTML you generate is not what is currently being
shown, but *your* conversion of the DOM objects into a text
representation. If you are doing that anyway, why not just send
the values and build the structure on the server side.

Or, if you really, really need to be sure what the user sees,
accept his values as a normal form submit, and then generate
a bitmap image displaying those values along with a secret word,
and have the user submit the secret word to confirm that he
agrees with the data in the image.
That way you know what image was displayed, and that he can see
images.

/L

 

[Evertjan.]

MC wrote on 16 jun 2008 in comp.lang.javascript:

[please do not quote signatures on usenet]

This is not an illogical slavery. The library is GREAT.

Wow, GREAT if you say so! I do not believe so.
That just means you are a willing slave to that greatness.

Everybody is

I wouldn't think everybody, as you did not ask or hear evrybody.
Are you a man or woman of superlatives?

hung up on why I want to do this and not the how.
DOES ANYONE KNOW HOW???

You cannot do this and you should not want to do this.
Wanting to do what is impossible is nice, but not productive.

The why, is I want to construct an archival image of the view a user
sees in a client browser.

1 html does only approximately show how different browsers, different sizes
and different OS'es show a window.

2 html is available on the server and can be directly taken from the server
by xmlhttp.

3 html does not show the changes made to the DOM on the browser.

[I wrote all these arguments before in this thread]

This library can be used to construct an
encrypted page view image while maintaining inner data and it is
easily renderable while encrypted by most browsers.

Impossible, if you mean "image" like most of us do.

What is "inner data", html being html?

What is "renderable" in the sense of a browser, a browser does not render
html, as html is the source as far as the browser is concerned?

What browser "encripts" the html?
Or do you mean parsing the html source to the DOM?

The archival image
will be used as a legal construct to document what a user saw in the
browser and may be used in court.

You must have a very naive judge to believe such.

Web sites do not come from a single
server so reconstructing what the server serves is inappropriate as
the client view may get content from dozens of servers to build a
single client view.

Could be true, but that is immaterial, only using clientside in-browser
javascript scripting.

You would need to conserve a screenview or a windowview, quite possible
with a seperate programme, but not just with browser scripting.

And even so, such view can be easily manipulated, so would not do for
juridical proof.

========================================

Remember you asked:
"How do I get HTML sent to server?"
[Which server, btw, since now you stipulate several servers?]

And not:
"How do I send a screenview to the server ?"

And I showed "sending html to a server" to be inappropriate for conserving
the view the user has seen on his or her screem.

 

[MC]

MC wrote on 16 jun 2008 in comp.lang.javascript:

[please do not quote signatures on usenet]

This is not an illogical slavery. The library is GREAT.

Wow, GREAT if you say so! I do not believe so.
That just means you are a willing slave to that greatness.

Everybody is

I wouldn't think everybody, as you did not ask or hear evrybody.
Are you a man or woman of superlatives?

hung up on why I want to do this and not the how.
DOES ANYONE KNOW HOW???

You cannot do this and you should not want to do this.
Wanting to do what is impossible is nice, but not productive.

The why, is I want to construct an archival image of the view a user
sees in a client browser.

1 html does only approximately show how different browsers, different
sizes
and different OS'es show a window.

2 html is available on the server and can be directly taken from the
server
by xmlhttp.

3 html does not show the changes made to the DOM on the browser.

[I wrote all these arguments before in this thread]

This library can be used to construct an
encrypted page view image while maintaining inner data and it is
easily renderable while encrypted by most browsers.

Impossible, if you mean "image" like most of us do.

What is "inner data", html being html?

What is "renderable" in the sense of a browser, a browser does not render
html, as html is the source as far as the browser is concerned?

What browser "encripts" the html?
Or do you mean parsing the html source to the DOM?

The archival image
will be used as a legal construct to document what a user saw in the
browser and may be used in court.

You must have a very naive judge to believe such.

Web sites do not come from a single
server so reconstructing what the server serves is inappropriate as
the client view may get content from dozens of servers to build a
single client view.

Could be true, but that is immaterial, only using clientside in-browser
javascript scripting.

You would need to conserve a screenview or a windowview, quite possible
with a seperate programme, but not just with browser scripting.

And even so, such view can be easily manipulated, so would not do for
juridical proof.

========================================

Remember you asked:
"How do I get HTML sent to server?"
[Which server, btw, since now you stipulate several servers?]

And not:
"How do I send a screenview to the server ?"

And I showed "sending html to a server" to be inappropriate for conserving
the view the user has seen on his or her screem.

Look,
This is not helping and its not constructive. Yes, the main html is served
by a single page but the inner content may come from dozens of servers. We
are trying our best to approximate and document the client view. And yes, I
can construct an encrypted image that is comprised of data elements using
this library. I don't care if you have a problem with that. The how is what
I am interested in. It seems that if you can't offer a solution, then the
problem is criticized. I thought pointy ears was the only one being
unfriendly in that manner here.
MC

 

[MC]

Sending the HTML won't give you that. It only gives you the structure
of the HTML, not what it *looks* like when displayed in a browser.
For that, you need a screenshot.

If you insist on converting the page's document structure back to HTML
and send that back to the server (including user-entered values in
form controls), you'll have to traverse the DOM structure and build
the HTML.

The non-standard innerHTML property only reads the original value
of input controls (i.e., "inputControl.originalValue", not the currently
entered value, "inputControl.value"). I.e., it misses the user entered
values.

This means that the HTML you generate is not what is currently being
shown, but *your* conversion of the DOM objects into a text
representation. If you are doing that anyway, why not just send
the values and build the structure on the server side.

Or, if you really, really need to be sure what the user sees,
accept his values as a normal form submit, and then generate
a bitmap image displaying those values along with a secret word,
and have the user submit the secret word to confirm that he
agrees with the data in the image.
That way you know what image was displayed, and that he can see
images.

/L
--
Lasse Reichstein Nielsen - (e-mail address removed)
DHTML Death Colors:
<URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

THANK YOU!
I appreciate someone trying to help rather than criticize!

Just sending the data back will not work, as the client view may have html
content from other sources in its view.

I understand that a screenshot would work...any ideas on sending one back to
the server based on a .js event? I would really prefer to have a data image
as I can encrypt that and still retrieve the data from it. This will allow
me to pull data from it and index it to a database while storing the image.
The image does not need to be perfect as a client view but as good as
possible.

Is there any way to traverse and build the HTML and get the user entered
data? This is the real question no one seems to be able to answer.

MC

 

[david.karr]

The why, is I want to construct an archival image of the view a user sees in
a client browser. This library can be used to construct an encrypted page
view image while maintaining inner data and it is easily renderable while
encrypted by most browsers. The archival image will be used as a legal
construct to document what a user saw in the browser and may be used in
court. Web sites do not come from a single server so reconstructing what the
server serves is inappropriate as the client view may get content from
dozens of servers to build a single client view.

Other posters have been making this point, but if you need to store
exactly what was viewed, storing the HTML will not do that, even if
you could accomplish that.

You might consider encapsulating the "legal" information into PDF and
archiving that. That would be a more reliable rendering of what "they
saw", because PDF rendering is less variable between browsers.

 

[Evertjan.]

MC wrote on 16 jun 2008 in comp.lang.javascript:

This is not helping and its not constructive.

Showing you the errors of your thought must be constructive and helpful,
even if you do not like the answer.

On usenet, you can ask questions, but you can not dictate the answers.

Yes, the main html is
served by a single page but the inner content may come from dozens of
servers.

A strange way to define "inner content of html".

The page as shown in a browaser window can have inner content in an
iframe or as a change in the DOM. but that is not part of the html.

You could reconstruct a form of html from the DOM, using innerHTML,
but it would not do the job and certainly not convince the judge.

We are trying our best to approximate and document the client
view.

I showed you it was impossible to do, using a send back of html.

And yes, I can construct an encrypted image that is comprised of
data elements using this library. I don't care if you have a problem
with that.

I is not about if you care or do not.
I seem to remember you are the asking party.

The how is what I am interested in. It seems that if you
can't offer a solution, then the problem is criticized. I thought
pointy ears was the only one being unfriendly in that manner here.

You are just incontent with the answer,
because it does not follow your preconceived ideas.

Not liking my answer does not change the fact
that if it is impossible, it just is.

How are you so sure it is possible?

 

[VK]

the main html is served
by a single page but the inner content may come from dozens of servers. We
are trying our best to approximate and document the client view.

You cannot do it in principle unless you have client-side installed
scriptable plugin to take screen snapshots and to submit them to the
server. This is the only way to go I guess if there is a legal issue
involved.
The problem is that the browser - any browser - does _not_ have access
to the HTML source used to render the current page. Yes, sounds crazy.
Yes, anyone can click View > Page Source or equivalent to see the
source: anyone can but browser cannot. What browser can "see" is the
DOM Tree resulted from the parsing algorithms and error correction
mechanics of this particular browser applied to the server HTML
source. Respectively by getting document.documentElement.innerHTML
(the whole page) or document.body.innerHTML (body only) you are not
getting the original source. Instead the browser is "reverse
engineering" for you the current DOM Tree into some HTML code which
is, being reused by this particular browser, should result to a copy
of the current DOM Tree which is by itself is a browser-specific
result of parsing the original HTML source. The results may differ
dramatically as you may guess. For a taste of it try for instance this
code in different browsers:

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<p>Hello!
</html>
<script>
window.onload = function() {
window.alert(document.documentElement.innerHTML);
}
</script>

So it is a dead end where you are working with now. Unless you consult
with your legal department and they conclude that server-side provided
HTML source and client-side resulted DOM Tree must be considered as
legally equal entities Actually the question sounds very
California-style. I doubt there are by far precedent cases like "HTML
Source VS. DOM Tree" or "John Doe and Al. VS. Internet Explorer HTML
Parser Document Forgery" and the like but who knows under this hot
sun.

I would still suggest to stop wasting your time for that. Instead buy
yourself a valid code-signing certificate and do either of two:
1) Require extended privileges for your signed script / ActiveX to
make cross-domain calls and to collect the original HTML sources
before rendering them.
2) Better yet make a signed plugin / ActiveX to make screen snapshots
and require to install it for each client.

Both ways are still rather silly in comparison with regular legal
alternatives but at least doable.

 

[VK]

The problem is that the browser - any browser - does _not_ have access
to the HTML source used to render the current page. Yes, sounds crazy.
Yes, anyone can click View > Page Source or equivalent to see the
source: anyone can but browser cannot. What browser can "see" is the
DOM Tree resulted from the parsing algorithms and error correction
mechanics of this particular browser applied to the server HTML
source. Respectively by getting document.documentElement.innerHTML
(the whole page) or document.body.innerHTML (body only) you are not
getting the original source. Instead the browser is "reverse
engineering" for you the current DOM Tree into some HTML code which
is, being reused by this particular browser, should result to a copy
of the current DOM Tree which is by itself is a browser-specific
result of parsing the original HTML source.

This is why btw the infamous Gecko's "phantom nodes" bug #26179
https://bugzilla.mozilla.org/show_bug.cgi?id=26179
remains a sample of unjustified silliness and stubbornness: because it
fights for a careful preservation of sorry leftovers of something that
doesn't exist in the browser's runtime nor accessible from within the
browser.
Someone just wanted to save its time on parse-adding extra spaces in
text/plain paragraphs like
<p>Lorem ipsum
dolor sit amet</p>
and to justify its laziness he brought W3C, traditions, standards and
nearly the Lord himself as a witness to prove himself right. :-\
An old story but still upsetting and still seriously influencing to
many coding paradigms...

 

[SAM]

MC a écrit :

Evertjan,

This is not an illogical slavery. The library is GREAT. Everybody is hung up
on why I want to do this and not the how.

I think you'll have to copy-paste(*) all the DOM in an hidden field sent
to the server when submitting (or on leaving the page).
But it's the user who decides to send that. Will he do it ?

DOES ANYONE KNOW HOW???

Evertjan told +/- how to do a copy, but certainly not how to receive it
without user's agreement.

The why, is I want to construct an archival image of the view a user sees in
a client browser.

I do not understand
(how to get a snapshot of the screen on the user's PC?)

This library can be used to construct an encrypted page view image

by 'image' you mean a picture ?
or just a representation (some code to show the expected view)

while maintaining inner data and it is easily renderable while
encrypted by most browsers. The archival image will be used as a legal
construct to document what a user saw in the browser and may be used in
court.

??? really ? are they mad ?

How do you reflect what did NC4 saw and what did Fx 3 or IE 8 ?
(NC4 doesn't know the DOM, IE 5 or 6 do what they want, no activeX on
Mac, and so on (plug-ins, java ... etc))
What about JS and Ajax (how to know if the user pressed this or this
button launching an XHR function that modified the page?)

But perhaps you want to illustrate what your server send to users ?
Why not to do the snapshots (for each environment and browser) by yourself?

Web sites do not come from a single server so reconstructing what the
server serves is inappropriate as the client view may get content from
dozens of servers to build a single client view.

You forget Ajax, Flash and certainly more.
An image will not show the hidden javascript nor what the Flash can do.

(*) the copy-paste of DOM isn't so easy
it seems to be the alone way because the DOM of a displayed page
can be modify at any time, changing the view

The real question is : how to get it, if the user doesn't send it.