Are any other boards going to be mobile? If so Tech Support is a must, I only ever resort to such devices when my PC isn't working. I'll test this out later on my PSP and will do my best to provide a screen shot.
Sure, eventually I'd like all the boards to have it supported.
I'll try it on my PSP tonight, and see how it goes.
Alright, it works good, but the PSP can already handle the site. Looks like win for mobile phones though.
This is really cool, I tried using 4-ch with my phone before but the pages were too large for it to load. I'll give it a shot as soon as I recharge it!
Thanks squeeks, Ive always wanted to browse 4-ch when on the bus or train
Eh, it didn't work so well for me on my phone. Viewing 4ch with such a small screen is rather annoying.
>>9
It's fine if you think it sucks, but you need to show me why. Maybe stop using a phone with a tiny screen?
whenever i try to view an entire post it doesnt work
http://4-ch.net/personal/mobile.pl/1193225109/
http://4-ch.net/personal/kareha.pl/1193225109/
>>11
As I've already asked, what phone, what browser etc?
>>12
a sony ericsson W810i, but that doesn't matter. if you use 4-ch:mobile on your computer you still can't see anything after:
"I thought it would pass, but it's been three weeks..."
http://4-ch.net/personal/mobile.pl/1193225109/1
http://4-ch.net/personal/kareha.pl/1193225109/1
Ah right, I've now fixed that problem involving truncating posts. Thanks, anonymous.
It looks great on the PSP, and is pretty good on the mobile phone, although obviously the small screen limits it quite a bit. Good job.
http://i10.tinypic.com/8gjdph3.jpg
http://i17.tinypic.com/8f2flon.jpg
http://i9.tinypic.com/6oxgol1.jpg
http://i15.tinypic.com/8fe4ncp.jpg
http://i15.tinypic.com/8e9l66g.jpg
http://i11.tinypic.com/87lf81j.jpg
Very nice, GJ!
Looks pretty good on my E-series Nokia (WebKit based browser):
http://lnk.nu/img140.imageshack.us/gwt.jpg
http://lnk.nu/img132.imageshack.us/gwu.jpg
http://lnk.nu/img110.imageshack.us/gwv.jpg
Now, if only I could post..
Not Acceptable
An appropriate representation of the requested resource /req/mobile could not be found on this server.
Available variants:
- mobile.pl , type text/x-perl
Additionally, a 406 Not Acceptable error was encountered while trying to use an ErrorDocument to handle the request.
> RewriteCond %{HTTP_ACCEPT} !(text|\)/(javascript|\)
if you end up using this, you should note that your server sends js files as application/x-javascript (the default for apache) instead of text/javascript (which i configured mine to send them as) and change the regex accordingly.
Wow, netfront really sucks.
Does putting a trailing slash on the end (eg. http://4-ch.net/dqn/mobile/ ) cause the same problem?
I'm rather curious as to what strange headers netfront is sending. Do you see anything unusual in http://services.4-ch.net/tools/headers.pl ? That stupid browser shouldn't be getting confused over a differing "Content-Location" header in a 200 response, right?
>>20
adding a trailing slash makes no difference.
the only things i see in the headers that look unusual at all are the fact that it's using a proxy and the insanely long accept header that doesn't include /, which most browsers do include if they send an accept header.
upon further investigation it appears that the proxy is responsible for the javascript problem... the 406 error is definitely coming from apache tho, and i'm pretty sure it's because the accept header doesn't include text/x-perl or /.
Interesting about the trailing slash not making a difference. Because in terms of the headers Apache sends (and I don't have a proxy between me and server) differs quite significantly:
curl -i http://4-ch.net/dqn/mobile
HTTP/1.1 200 OK
Date: Sat, 22 Dec 2007 08:58:02 GMT
Server: Apache/2.2.3
Content-Location: mobile.pl
Vary: negotiate,Accept-Encoding
TCN: choice
Transfer-Encoding: chunked
Content-Type: text/html; charset=shift_jis
Now see above, I thought it was the Content-Location or in fact the TCN header that might have been stumping it, because, looking below...
curl -i http://4-ch.net/dqn/mobile/
HTTP/1.1 200 OK
Date: Sat, 22 Dec 2007 08:58:41 GMT
Server: Apache/2.2.3
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=shift_jis
All of those potential problems aren't present when we trail with slash. This makes little sense. Let's start looking at headers from static pages:
curl -i http://4-ch.net/mobile
HTTP/1.1 200 OK
Date: Sat, 22 Dec 2007 09:11:11 GMT
Server: Apache/2.2.3
Content-Location: mobile.html
Vary: negotiate,Accept-Encoding
TCN: choice
Last-Modified: Fri, 14 Dec 2007 00:07:42 GMT
ETag: "1dc165-8c2-d9ea6f80;38f78f00"
Accept-Ranges: bytes
Content-Length: 2242
Pragma: no-cache
Content-Type: text/html
So browser has no issue requesting this page, which is also being "manipulated" by MultiViews like the addresses above. What I can deduct from this is that firstly the client is to blame for all of it's own problems, and secondly, it's sending headers or something it shouldn't. Multiple choice requests shouldn't be occurring. Request http://services.4-ch.net/tools/headers and then do another request with the .pl, remove the IP/host bit and paste me the rest. I'd like to see exactly what's being sent.
$ curl -H "Accept: text/html" -i http://4-ch.net/dqn/mobile
HTTP/1.1 406 Not Acceptable
Date: Sun, 23 Dec 2007 03:20:57 GMT
Server: Apache/2.2.3
Alternates: {"mobile.pl" 1 {type text/x-perl}}, {"error.pl" 1 {type text/x-perl}}
Vary: negotiate,Accept-Encoding
TCN: list
Content-Length: 542
Content-Type: text/html; charset=iso-8859-1
...
netfront's accept header is this:
Accept: application/vnd.wap.xhtml+xml, application/x-pmd, application/vnd.phonecom.mmc-xml, audio/midi, audio/vnd.qcelp, application/xhtml+xml; profile="http://www.wapforum.org/xhtml", application/x-pcs-mcd+xml, multipard/vnd.sprint-pre-cache, multipart/mixed; q=0.5, multipart/related, text/vnd.wap.wml, text/vnd.sun.j2me.app-descriptor, text/x-pcs-gcd, text/css, application/ecmascript, image/png, image/gif, image/jpeg; q=0.5, image/vnd.wap.wbmp; q=0.2, application/sdp, audio/qcelp, audio/mp3, audio/mp4, video/mp4, audio/3gpp2, video/3gpp2, audio/3gpp, video/3gpp, audio/amr, audio/aac, audio/aacplus, application/pmd, application/m3g, audio/mpeg, audio/mid, text/plain, video/x-ms-asf, video/x-ms-wmv, audio/x-ms-wma,text/html;q=0.062,image/gif;q=0.062,image/x-jng;q=0.062,video/x-mng;q=0.062,image/x-mng;q=0.062,image/bmp;q=0.062,image/x-bmp;q=0.062
Please, do me a favour, complain to Sprint/Netfront/whoever and remind them that their implementation of a "browser" on that phone sucks. I've stuck the stupid file extensions so save you and any other netfront users the grief of having to click twice.
Also I was curious about the rest of the headers netfront sent, not just the accept mime types.
>>25
here are the rest of the headers:
(IP and Host removed)
Date: Sun Dec 23 05:29:08 2007
Request: GET http://services.4-ch.net/tools/header.pl
(Accept removed)
Accept-Charset: UTF-8, us-ascii, iso-8859-1, UTF-16,*
Accept-Language: en;q=1.0,es;q=0.5
Cache-Control: no-cache
Clientid: (removed)@sprintpcs.com
Host: services.4-ch.net
Pragma: no-cache
User-Agent: Mozilla/4.0 (MobilePhone SCP8500/US/1.0) NetFront/3.4 MMP/2.0
Via: 1.1 kscymbmagprx03-int.nmcc.sprintspectrum.com:8090
X-Network-Type: IS2000
X-Wap-Profile: "http://device.sprintpcs.com/Sanyo/SCP8500/1002SP.rdf"
most of the time the X-Network-Type is EVDO, it's IS2000 when i'm at home because my house is right in the middle of a 100 square foot hole in sprint's coverage (insert conspiracy theory here).
adding a trailing slash, removing the .pl, etc only changes the Request one.