QueryString inconsistencies?

[cLFlaVA]

Hi everyone...

This seems to be browser/machine specific, so please let me know if I'm barking up the wrong tree.

I have a line of code as follows:

Response.Redirect( "frmForecast.asp?qryProjectNumber=" & strProjectNumber & "&qryCostType=" & strCostType & "#" & strGoToBudgetEntity )

In all browsers I've tested, this redirect works fine. However, the frmForecast page then parses the value of qryCostType from the QueryString and does stuff based on the value.

On my machine, in both IE and FF, this worked perfectly. The value, when printed for debugging purposes, held "71".

However, on another user's machine, following the same order of events, it printed "71#BudgetEntity9", which oddly contained the anchor.

Any idea what causes this?

Thanks



*cLFlaVA
----------------------------
[tt]"quote goes here"[/tt]
[URL unfurl="true"]http://www.coryarthus.com/[/url]

 

[onpnt]

I don't have a very good explanation to be honest but I tried some things to see if I could help

I do think that the browsers are going to be inconsistent with the # as a delimiter. If you Server.URLEncode then it will print out fine.

I tried this to try and get your results

<%
Dim strCostType : strCostType = "4"
Dim strGoToBudgetEntity : strGoToBudgetEntity = "Entity"
Dim strProjectNumber : strProjectNumber = "71"
Response.Redirect("frmForecast2.asp?qryProjectNumber=" & strProjectNumber & "&qryCostType=" & strCostType & _
								Server.URLEncode("#") & strGoToBudgetEntity)
%>

<%
Response.Write Request.QueryString("qryProjectNumber")
Response.Write "<br />"
Response.Write Request.QueryString("qryCostType")
Response.Write "<br />"
%>

This worked good but if you take out the URLEncode you get only the 4 from qryCostType

[sub]____________ signature below ______________
The worst mistake you'll ever make is to do something simply the way you know how while ignoring the way it should be done[/sub]

 

[Sheco]

If both browsers are requesting the same ASP then there must be something different about the HTTP request.

If so, you could make a little page like this:

<%
for each foo in request.servervariables
  response.write foo & " = " & request.servervariables(foo) & "<br>" & vbCrLf
next

... and then compare the output of the page when you connect to it with both browsers... maybe something will stand out.

 

[Tarwn]

According to the RFC on URI's, browsers are supposed to split out fragment links (#name) first, then parse the rest of the URI. Basically this means that a fragment link should be the absolute last piece of the URI so that when it is split out you do not lose your querystring. So:
Correct:

http://www.abc.com/def.asp?a=1&b=2#somelink

Incorrect:

http://www.abc.com/def.asp#somelink?a=1&b=2

However, there is no rule about whether the browser includes the fragment when making a request to the server or not. I did read somewhere that .Net is ok with you sending either a fragment or a querystring, but that when you send both it includes both as the querystring. It seems odd to me that this would only show up based on a specific client or client browser version, but I suppose if MS managed to screw it up in .Net... (this is a feature, according to MS rep your only supposed to send one or the other, disregarding the standard)

Something you might try for informative purposes would be to Response.Write Request.Querystring and see if the fragment is outputted from your machine then the "other user"s machine as part of the full Querystring value.

A quick and dirty workaround would be to append a final & before your # so that even if the fragment is included as part of the Querystring, it won't get attached to one of your existing values and will basically just be shuffled off to it's own variable. This seems to be valid client-side and gets it out of your hair server-side.

-T

 

[cLFlaVA]

thanks guys...

Tarwn,

I was creating the query string as you outlined in the "correct" example above.

my work-around for this, as a short-term fix, was to take the Left() of the string if the string contained a #. this seems to work fine.



*cLFlaVA
----------------------------
[tt]"quote goes here"[/tt]
[URL unfurl="true"]http://www.coryarthus.com/[/url]

 

[Tarwn]

Add the ampersand to the end like I had above, that way you don't have to worry about trimming whichever happens to be the last item. On the other hand, your current method does support job security